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.

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.

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.

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).

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.

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.

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!

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 :-)

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.

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.)

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.