Workflow for maintaining local repositories of remote subversion repositories

Question

I understand the importance of using version control and I am trying to learn as much as possible so I can setup SVN for our company web development projects. Right now we all work from a single dev copy and it is messy at best.

Many of our users work remotely and the dev server is on a slow internet connection. From what I have read it is good practice for users to each run their own SVN repositories locally to track their own changes, and then sync that with the server repositories. What is the best way to accomplish this?

Otherwise, is it better for each user to just have their own working copy of the server repository and only work from that?

Since the server is on a slow connection, is it better for each developer (team of 7 at this time) to have their own working copy on the dev server or locally on their machine?

I am also looking at GIT on Windows, but SVN is very mature and has plugins for Visual Studio we can leverage.

Answer 1

Certainly GIT would fit your requirements totally. It's fast, You merge with GIT just like that.

Although for me if You'd stick to the SVN:

• consider to use branches. Then the main trunk repository would stay clean. Only problem then is merging. But that IMHO is better than tracking it locally (unless you use git).

• Check in only important working changes at the end of day.

• plan your work forward, schedule tasks, assign task to proper persons, then You'd have less merging and faster development time.

Answer 2

... git evangelist reporting for duty! ;)

As noted by sbi, this sounds like an environment best suited for a distributed VCS (like git). However as you may have noted, git on Windows is not very mature yet. It's getting there fast though. In your case it may be interesting to know that integration with Visual Studio is not very nice yet. There is GitExtensions which integrates with VS, but it's not that brilliant. Alternatively there is TortoiseGit.

There are other distributed VCSs that may be interesting, like Mercurial or Bazaar, which may have matured a bit more. Not sure about that though. Haven't used them in ages.

I would not go down the road to take SVN as a distributed VCS. It is not developed with that use case in mind, so it's going to be cumbersome to implement properly. Even if VS-Integration is nice. Merging will become troublesome.

On the other hand, VS-Integration is IMHO not as important. It's better have not-so-good integration than have no version control at all. And I have yet to see the tool that does everything perfectly. So I would recommend looking into truly distributed VCSs. The concept may be frightening/confusing at first, but it's well worth the trouble.

edit: I said that git is not very mature on Windows. It's not quite that bad. It is not as mature as it is on Linux, but it is very usable nonetheless!

Answer 3

Your second paragraph is like a softball pitch for the git crowd. Git is definitely my suggested choice. Honestly, any Distributed Revision Control System (ex. Mercurial) would be fine too, but git is just my (and many other developers') hammer in the toolbox.

You don't need to go through the headaches of managing a separate subversion repository for each developer; a DRCS has that feature baked right in. Each developer clones the master repository, performs work and commits/branches/etc as much as they'd like on their local machine. Then when they are ready to promote code for others to view, they push all their revisions/branches back to your internal repository.

I've honestly only been using git for a few months, but I'll never go back to subversion now. You can get plenty of great information from the Pro Git Book -- Free viewing online, but please buy it for reference if you find it helpful!

Answer 4

You knew this was coming: I would go with GIT.

SVN actually does not play well (at all) with multiple repositories. While there is now some support for syncing across multiple repos, the situation you're describing would quickly become a nightmare. SVN in most circumstances is really best used with one single repository that is accessed by all users' working directories.

Git, on the other hand was designed to do exactly what you described: multiple repositories with commits moving between them.

Check out tortoiseGit, and be prepared for a learning curve. However, in the end it will probably be much closer to what you want.

If you go with SVN, I'd stick with the single repository, unless you use an extension like WANdisco. You can use svnsync, but read up on the limitations (read only repositories, etc).

Answer 5

I you use SVN, I would also use SVK with it as well to offer disconnected access to your repository. But in the case you describe, I too would proffer git or mercurial as a better option. Both support sending patchsets to the remote side for integration into a "master" tree, if such is what you want.

Answer 6

Since your team is small (7 people) SVN is perfectly fine, and has a rich set of (Windows) tools which are mature and easy to use.

We use VisualSVN (http://www.visualsvn.com/) as our server. Its a snap to set it up, and its free. The clients offered by the same company support integration with Visual Studio, and would have a small liscensing cost for your small team.

Since Git is so trendy and popular, I'm expecting lots of down-votes, but its still primarily a linux tool. TortoiseGit doesn't work very well yet, and the fact is that its a VCS made by an OS developer - it would be the same as using a solution developed by MS.

Mercurial's TotoiseHg is still much better on Windows that its Git equivalent (speaking from experience).

Both DVCS solutions will add additional training time for your team as you will need to develop a process that everyone should follow. Also neither have truly viable Visual Studio itegrations.

When choosing between a server based VCS like SVN vs a DVCS solution, its important to note (especially with remote users) that you will be relying on them to back up their local changes if they are using a DVCS solution (at least until those changes are pushed upstream). Also, you won't have any visibility into those changes until they are pushed upstream.

Finally, I'm not sure that any of the (D)VCS solutions have much advantage over each other when dealing with a slow link.