How do I avoid Complicated Merges in Subversion?

Question

I'm new to Subversion (SVN) coming from a Visual Source Safe (VSS) background. In VSS the person editing a file checks the file out and it locks the other users from editing it through Visual Studio. I understand that SVN is a concurrent model allowing multiple people to work on the same file and later merge the changes together. My question is this:

1. What is the best approach to avoid having users editing the same file(writing tons and tons of code) and either facing a complicated merge for their changes or even worse writing a ton of code only to find that the file is locked by another user?

2. Is there a way to notify a user when retrieving a file that it is currently being edited by another user or currently locked by another user?

Other Details:

Using VisualSVN Server as SVN Server.
Using TortoiseSVN and AnkhSVN clients.

Woolsack

Thanks everyone for all the suggestions and setting me straight. – Woolsack

A year too late, but I really have to recommend reading the SVN manual. It's written in a casual, pragmatic manner and reads like an extensive SO answer. – Ingratitude

Answer 1

I'm also a former Visual Source Safe user. Merges used to drive me crazy until I realized that it is not a technology problem, but a people issue. When using VSS, most developers try to get as much work done as possible, before they have to check in code. This behavior is what was contributing to complicated merges.

Here are a few things to mitigate this:

• Always update your working copy before starting
• Check in often. This will make the code changes smaller, which will be easier to auto-merge
• Do not leave working code unchecked
• Developers should create their own branch, if the changes will take several days or longer

Those things helped immensely, especially as the teams I worked in kept getting bigger and bigger. Replicating the lock behavior from VSS is a very bad idea, and will cause more problems. Just embrace the new workflow.

If you still want to use a tool, then I suggest that you look at SVNMonitor.

Guntar

Thanks for recommending SVNMonitor. – Woolsack

you missed one critical thing to mention that makes Branching a joy to work with. Update often...trunk changes people have checked in to your branches. Same as you said in point #1. Do the same with your branch..it shouldn't be treated any differently. If you continually update your branch often with changes people have checked into trunk on a daily basis, you don't end up with any merge hell at the end because code in your branches are pretty much up-to-date or close to the latest of what's in trunk because you religiously updated your branches all along! Small pains daily makes life easy – Hunker

Answer 2

I would like to suggest taking a different approach to using subversion.

• You should get updates frequently.
• You should also check in early and often.

With this approach, merging is usually infrequent and happens automatically. In the case of conflicts, these are often smaller.

Stellular

Answer 3

A couple of points that I encountered at a previous place where we went from a lock-based system to SVN.

It's not really a good idea to try and replicate lock-edit-unlock behaviour in SVN as it has been designed in such a way that you don't need to work that way. The merge algorithms used by SVN are pretty good and I've only encountered a few occurrences where manual intervention during a merge was required. It's surprisingly rare that two people working on the same file will actually touch the same line(s) and the latter is often the only time when manual intervention is needed.

SVN is really designed to be used in an environment where you update from the trunk or your current branch often. If you have to do longer-term work or work that changes a lot of code in a file, you might be better off using a branch to do the work and merge that back in. Yes, you'll have to go through some merge pain from time to time but it's considerably less pain than you get with a system that wasn't designed to work that way.

If you're trying to use SVN not as 'native SVN' but as VSS with a different name, it will be painful and it will not be worth the hassle. Get comfortable with the new paradigm and you'll be surprised how much nicer it is to work that way compared to the old "only one user edits a given file at any given time" routine.

Radiobroadcast

Answer 4

First of all, it is probably wise to avoid writing 'tons and tons of code' without checking files in, if at all possible. If you have a good unit test suite (and if not, why not? :), then as long as you are checking in on the green bar, frequent commits are best.

Then, if you do have changes that take a long time by necessity, it is worth doing an svn update periodically to stay in sync with the trunk as closely as possible. Subversion is pretty respectable at merging (compared to VSS) and will handle the majority of stuff well.

Anything it can't handle, it will put into a conflicted state, leaving you to resolve the conflicts with a merge tool of your choice (I recommend WinMerge for this, it's ace).

Fumigator

Answer 5

The only time you might want to use the old VSS style locking model is with binary files (MS-Word docs, etc) that you want to version, but that SVN can't automatically merge changes from multiple sources.

Liggins

Answer 6

I would take some time learning about the "check in dance"

Here's a dime cast on it.

There's also multiple articles on the web about this and how to alleviate the pain.

Molli

Answer 7

Not a problem. Using Tortoise SVN, do this ...

1. In Windows Explorer, right-click the file(s).
2. Choose "Tortoise SVN" and then "Get Lock..."
3. In the Lock Files dialogue box, fill in your reason for the lock.
4. Click OK.

Ninetieth

technically a correct answer to his question, but not a good solution to the problem. When using SVN properly, there's very little reason to use locks. – Tenuto

We've explored using the lock command and still have the "problem" of other users not being notified about the state of the file. – Woolsack

Answer 8

SVN is a concurrent model allowing multiple people to work on the same file and later merge the changes together.

I think it's more about working on the same project that consists of a bunch of more or less of independent files. Working on the same file and merging the results is certainly possible, and does happen every now and then, but it's definitely not the default/desired mode of operation. So:

• Update often.
• Commit often.
• Avoid large classes/files (1000 lines is way too much). This also has additional benefits :-)

Bucovina

Answer 9

Although SVN has a lock command, the most common way to use SVN involves the optimistic approach to locking.

That means you and I can edit the same file and not worry much about it (most of the time we won't because we'd be working on different parts of our project). If I'm first to commit changes to the file, then your commit attempt will fail. That's when SVN will notify you.

You will then have to run the "Update" command, that will (most likely) automatically merge my committed changes with your local changes and then your next commit attempt will go through.

To avoid getting into trouble with this optimistic approach: as others suggested, commit often and don't commit too much at once!

Quaggy

Answer 10

Short answer:

1. Update often. Checkin early, checkin often. If you work on something for longer (more than one or two days), consider creating a feature branch.
2. No.

Somewhat longer answer:

If more than one developer does "tons and tons of changes" on the same file, something is fishy either with the way your developers work or with the way features are spread over different files. I've been working with CVS and SVN in teams of different sizes and IME there are very few cases when merging becomes a real problem. (These usually are changes of fundamental services like string, logging, error handling etc. that require to change just about all code. Such cases require some human interaction and planning to go smoothly.)

Gaulish

Answer 11

I agree with everyone else, in so far as possible check in early and often (it isn't always possible). If you're doing something complex and new it can be done on a branch - the same rule applies, commit early and often and where keep your branch as up to date as practical with code from the head.

In our experience for the most part people tend not to be working on the same file or at least the same part of the file at the same time (in VSS you couldn't so your working patterns probably already support you in this).

One more key thing - make sure that everyone is using the same rules for use of tabs/spacing, for layout and for formatting, this is good practice anyway but the more consistent you are the less likely you are to find "differences" between code files that don't really exist.

In addition I'd recommend you look at continuous integration i.e. having a build server, this provides considerable benefits in terms of confidence that your committed code will build in a "clean" environment and, if you are suitably equipped with tests, will give you futher confidence that it still works - even after a complex merge process.

We use TeamCity which we've found to be excellent - but there are others.

Sessile

The "quest" for a continuous integration build server is what led me in the path of using subversion. CruiseControl.NET is what we are prototyping our build server with. – Woolsack