Using SVN in Visual studio via VisualSVN Server and AnkhSVN

Question

We are already using TFS for our team and we have so many problems with it. But we're not gonna go that way in this topic.

I'm trying to replace TFS with SVN for our team. I installed the VisualSVN Server on our Windows server and we use AnkhSVN for client side. There are no issues using these software. We have access to everything and everything works fine.

However, I'm having a problem with multi-user file editing. In TFS when someone opens a file and make a change, that file will be checkout only for that user and no one else in the network can change that file. But in SVN when I open a file and make some changes, someone else can do the same.

And in the end, when I commit my changes and they do the "Get updates", their files get conflicted.

So my question is, how to solve this problem?

Answer 1

Read Version Control with Subversion book (SVNBook). SVNBook is the Bible of SVN and must-read for Subversion administrators and users.

Chapters you may find helpful:

• "Fundamental Concepts".
• "Basic Usage".

Subversion supports Copy-Modify-Merge and Lock-Modify-Unlock versioning models and both of them take care of the situation when multiple developers need to work on the same files. For example, multiple users working on the same file following Copy-Modify-Merge model can work in parallel and resolving conflicts (should any occur) is one of the basic steps in this workflow, however in most cases you should avoid them.

On the other hand, with Lock-Modify-Unlock model (the one you are used to as TFS user) a user can lock a file (i.e. prevent others to modify it while he is working on some change) then commit the change and unlock the file allowing others to start modifying it.

Please read SVNBook | Version Control Basics: Versioning Models section.

Read more about Locking feature in Subversion in SVNBook.

Answer 2

It sounds like TFS continued VSS's usage of exclusive locking. Switching to the more sane model used by modern VCSs can take some getting used to.

Subversion utilizes a copy-modify-merge model. It allows multiple people to work on the same file at the same time, and any conflicting changes are then merged by the two users when the second one commits his changes to the repository.

This may seem counter-intuitive, but it's far better than the exclusive locking you're used to. In an exclusive locking model, if I need to edit lines 1-20 of a file, I have to wait until you're done with lines 500-600 before I can do anything. If you go on holiday for 2 weeks, leaving that file locked, I'm completely stuck.

If you can't let go of the exclusive lock model (which, on the whole, will slow you down), use the svn:needs-lock attribute on all of your files. This will mark files as read-only in each user's working copy, forcing them to acquire a lock to do any work (or go to their filesystem and unset the read-only attribute).

The point of locking in Subversion isn't to enforce airtight control; on the contrary, there are several (easy) ways around it unless you take additional steps at the server. Rather, the point of Subversion locking is to get developers talking to one another about potential conflicts before they happen. But Subversion handles most conflicts in plain text files (source code) decently, so even if you do have conflicts, they're not too onerous to unravel.