views:

152

answers:

5

We (small team) currently have our Visual Studio projects on a network drive (no version control). I would like us to start using version control, so I thought I'd install Subversion and put all the projects into an svn repository.

Now the question is: Where should we put our working copies?

  • Option A: On the local hard drive. Advantage: Compiling will be fast.
  • Option B: On a network share on the server (one directory per user). Advantage: All working copies will be included in the daily backup.

Ideally, I'd like to have both advantages but I guess that's not possible (at least not without reworking our backup strategy to include the workstations). Or is it possible? Or are there any other points in favor or against options A and B?

+3  A: 

are you using C++? Compiling is slow enough, don't underestimate the effect of compile times on your productivity. There are lots of free backup solutions for your local workstations.

At work we use TFS set up to only have local copies of files we've changed. Every time I open a file which isn't cached it lags for a few seconds to go fetch it. Excruciating.

Dustin Getz
+7  A: 

I would stick with option A for a simple reason: that way developers will be more likely to commit their changes instead of leaving working copies lingering around because they know they are being backed up. Set up the svn server and put it in a backup schedule.

Otávio Décio
+3  A: 

I've always found that there are security issues with running code from a network drive, so I'm gonna say go local and check in often.

In addition if you start using tools like visualsvn or tortoise they are much more likely to be performant on a local drive instead of the network.

Jason Punyon
+6  A: 

Go with option A. If you back-up your subversion repository by backing up your subversion server, there is no need to back up your working copies*. When changes are committed into SVN, they get transferred to the SVN server, so by backing up just the server you are in effect backing up the working copies barring any uncommitted changes.

In addition, Subversion is very optimised for network transfer when communicating with the SVN server, but is quite heavy on disk usage/access for the working copies. By putting the working copies on a remote file share, you are getting the worst of both scenarios.


* any changes not checked into to SVN will not be backed up, but I would advise that you encourage people to commit regularly. If this is not easy due to partially-complete functionality, take a look at branching in SVN. You could give each developer their own branch to develop on, and only merge their changes back into the main trunk once changes are complete.

adrianbanks
+1 for the emphasis on not backing up working copies. Encourage your team to commit early and often, or work on private branches if that suits your development style.
the_mandrill
Agreed - check in often, and branch if what you are working on is not suitable. That being said, it would be trivial to back up the developers workstations, so why not do that in addition?
Bryan Batchelder
branching in SVN is technically possible, but in my practical experience, excruciatingly frustrating and completely useless.
Dustin Getz
Where I work, we do it all the time. We currently have several feature branches on the go, as well as a few personal branches for individuals.
adrianbanks
+3  A: 

Definitely local for the aforementioned performance reasons, although I'd say that probably goes for any language.

Your cited reason for keeping them on the share is backups. If that's the only reason, I can tell you my experience in working with source control providers of various sorts has led me to the discovery that usually if you lose your local changes (very very rare by the way), they weren't so many that you can't recreate them. Your source repository should be on a backed up drive, so the vast majority of your code is safe. It's only the current tasks' worth of code that would be lost in the event of a drive failure. If you're concerned about that, promote small enough units of work (if possible) that no one would lose more than a day's work. Or I suppose you could branch your code if you have larger units of work and commit to the branches daily and merge them back to the main trunk at more convenient times.

Jim Leonardo
In addition, you can encourage developers to have something like SyncToy run overnight, so that if a developer does accumulate more than a day of pending changes, those pending changes will get backed up. This guarantees (ahem) that no developer can lose more than a day's work even if they don't commit for several days.
itowlson