Question

Here's the requirement:

  1. C# classes need to be shared among a group of 5 developers.
  2. If one developer starts editing a class, it should be automatically locked for others
  3. Others can edit that class, only when the current developer releases the class

I understand that Git is a distributed version control system, whereby complete local repositories are created. Merge functionality has to be used for creating a consolidated file.

I have also tried Svn, but even that uses a Merge tool.

I have a small team, and I don't want to use Merge Tools. Which is the best way to accomplish this?

Was it helpful?

Solution

SVN does support this kind of workflow with its locking feature.

Read the section on locking in the SVN Book v 1.7 - it goes into plenty of detail.

As far as Im aware git does not support a locking workflow.

Apparently Team Foundation Server also supports a locking workflow, but I'm not familiar with it.

I will add that i do not think this a good way to work unless you absolutely have to (eg binaries or hard to merge files like model xml). Regular team communication and defensive programming should mean that the vast majority of code merges will be handled automatically by your version control system.

Merging is just a part of collaborative development. Nobody really wants to use merge tools, but IMO having to do an occasional (sometimes messy) merge is a far better prospect that having to wait until someone else is finished with a file before I can make my change - changes which are very likely NOT to conflict with others changes anyway. Especially in a small team.

You should also not (as mentioned in comments above) need a resource dedicated to Merging. A merge is best done by two people.

  1. The developer with the conflict, and
  2. The developer who committed the last change (that has caused that conflict.)

If these two can't work it out pretty quickly, or you really do need a resource just for merging (which I have seen occur even in smallish teams of around 10 developers) you have problems.. such as;

  1. The code is monolithic/highly coupled and needs refactoring
  2. The developers are not committing atomic changes.
  3. Using svn and a complex branching strategy (scary)
  4. Developers are not talking to each other (Just a 10 min standup/day would help)

Good luck!

OTHER TIPS

Apache Subversion 1.8 features major improvements that make merging and solving conflicts easier. New automatic merges are definitely worth testing!

As @mounds already mentioned, you can use pessimistic locking kind of workflow with Apache Subversion. See the SVNBook | Lock communication section. In such case Visual Studio with VisualSVN will prompt you to lock a file before you start modifying it.

Note that such approach should be used with those files that can't be merged. So~, Embrace Merge!

Users and administrators alike are encouraged to attach the svn:needs-lock property to any file that cannot be contextually merged. This is the primary technique for encouraging good locking habits and preventing wasted effort.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top