4

My company manages a lot of web sites, and we are currently working without a VCS. I want to propose a VCS for a few reasons, but I think our requirements may be too unique. We work off of a shared drive that is mapped to windows explorer that has a mirror for each site. When edits are made they get pushed to staging, then when approved to the live site.

I'm not too familiar with VCS, but i have looked into Git and SVN, and I don't think we would be able to use them (correct me if I'm wrong). The problem is, we have so many sites, and we are constantly working on different sites, that keeping a local version of every site to push to the shared drive would be too much.

What i picture, ideally, is something that is stored on the shared drive that the developer can "branch" and work on a temporary file that merged back to the file that the developer opened. Also, it is important that another developer that has never worked on one of the sites before be able to start editing without too much setup. Having a system that tracks changes without changing our workflow too much (or no one will use it or even consider implementing it) and gets rid of the tons of "*_backupTodaysdate.html" files is the goal.

Improve this question
5
  • git can do that but i wouldn't allow the repo to be shared directly via the file system
    – Daniel A. White
    Commented Aug 16, 2016 at 1:10
  • 1
    How many people? How many projects? How many files in each project? Is there shared code between the projects? What is the shared drive doing? Just storing the files developers work on? What's the process for moving edits to staging and then the live site?
    – Winston Ewert
    Commented Aug 16, 2016 at 1:24
  • What is it you're really trying to avoid? Do you want have a LAN-only repository without worrying about the details of setting up a common server? Look at Gitlab or Gitlab Enterprise. Alternatively here's a decent tutorial. Do you want to have an approval process where commits can be rejected? Learn how to use branches effectively.
    – Assimilater
    Commented Aug 16, 2016 at 2:04
  • 2
    "keeping a local version of every site to push to the shared drive would be too much" - that's not how it would work. Only developers currently working on a site would need a local copy. When they are finished they remove their local copy because all relevant changes have already been submitted.
    – Brandin
    Commented Aug 16, 2016 at 5:47
  • How do those edits get pushed to staging? Is there a job running that looks for updated files?
    – RubberDuck
    Commented Aug 16, 2016 at 9:48

3 Answers 3

Reset to default
6

I would quit using a shared drive for shared editing. Go with a proper version control system and personal work spaces. Shared work spaces lead to all sort of issues including lost changes.

There is no reason to have all the sites checked out all the time. Checkout the sites you need and remove the related work space when you are done with the site. Your work flows will need to change accordingly.

I'll avoid repeating a lengthy answer. This question is similar to: What version control system can manage all aspects?

Improve this answer
1
  • your right, a shared work space would never work. cloning editing pushing and deleting the clone would be the only/best option
    – Erik Stagg
    Commented Aug 16, 2016 at 23:53
3

The Short Answer is: DON'T DO THAT! This won't just end in tears. it will probably end up on the 10 o'clock News as a workplace mass shooting!

With modern DVCS (Mercurial or Git) there is no sane reason to use a shared drive / directory for anything! Each dev has their own machine / directory. They pull from a "master repository" (although with a DVCS this is more of an opinion than a fact), they do whatever, and then they either push to the master, or request that someone higher up the food chain pull from their repository.

Our standard workflow is N dev machines with their own copies, a staging repository on the production machine (or an exact duplicate), and a master / stable repository. We have scripts to handle most of the scut work, including a revert script to go back to the previous version now just in case all hell breaks loose when the production server goes Tits Up on the latest "stable" release!

Improve this answer
4
  • Unfortunately getting rid of our shared drive is not an option, and completely changing our workflow is also not an option. What I am looking to do is work Git into our existing workflow, changing it the least amount. We are a small office and most, if not all, people do not like change. I think if we were to clone from the shared drive (as a master repository) and push back to the share drive, that would be the best solution for us.
    – Erik Stagg
    Commented Aug 16, 2016 at 23:49
  • 1
    I'm not trying to attack you or your group, but what you are describing is something out of the 1980's (or earlier). Disk is cheap, machines are cheap, local network bandwidth is cheap ... explaining to your customers about why you just hosed their website is not cheap. 'Not liking change' is about the weakest argument I can imagine for continuing a workflow like this. If I were your customer and I knew about this ... I would find another vendor. Seriously.
    – Peter Rowell
    Commented Aug 17, 2016 at 2:30
  • Don't say "I'm not trying to attack your company" and then continue by attacking my company. I agree with you on your ideal workflow, but the reality is, I don't run my company. I have to pitch this idea to the higher ups, and if I say "I'm going to change how we do everything, and that change will require bigger hard drives for every developer, and lots of maintenance" I will be pushed out the door. If your not going to help me with my situation and instead criticize me for being in that situation, then you might as well not comment
    – Erik Stagg
    Commented Aug 17, 2016 at 4:04
  • 1
    In case you missed it, I did give you advice. Instead of using vague statements like "bigger hard drives" and "lots of maintenance", let's use real numbers: 1TB HDD -- $50 (x2 if you want to back it up); Git or Mercurial + GUI + docs and tutorials -- free; retrain time for developers -- 1 to 4 hours. Cost of losing one (1) customer -- $1,000-$5000/year (?). If they fire you for saving them money, and possibly the company, then it's time to reconsider who you are working for.
    – Peter Rowell
    Commented Aug 17, 2016 at 16:39
3

The problem is, we have so many sites, and we are constantly working on different sites, that keeping a local version of every site to push to the shared drive would be too much.

This is not an unusual situation in the least. I regularly use git clones of 20 microservices I have push access to and another 10 or so from open source projects or other teams in the company I have dependencies on. I still have around 200Gb of free disk space, but if I didn't, cloning typically takes under 10 seconds. I think nothing of cloning a repo just for the duration of a code review, for example.

My suggestion is to just try git out on your local machine for a few days, so you have a better idea of what the workflow and overhead would be. Svn is a little harder to set up for local use, but might be a better fit if you share a lot of files between projects in a hierarchy.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.