1

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?

Ish Goel
  • 315
  • 1
  • 7
  • 16
  • 4
    Why would you ever choose pessimistic locking for a VCS? – Matt Ball Jun 15 '13 at 13:45
  • One way would be to work serially. When a developer starts on a task all others stop working until he is done... – Klas Mellbourn Jun 15 '13 at 13:46
  • 4
    Embrace Merge. It works. – Mitch Wheat Jun 15 '13 at 13:48
  • 1
    By the sounds of your requirements, Git is the furthest thing from what you want. I would still recommend it. IMHO, Git is the version control tool that is the best at merging, that makes it easiest to do. That is a great reason to use Git. – Klas Mellbourn Jun 15 '13 at 13:52
  • I don't want to dedicate one developer only for merging the different versions. Lets say, they arn't such experts for consolidating different versions, resolving conflits. With locking mechanism (although cliched) it will help me get a Consolidated version always – Ish Goel Jun 15 '13 at 13:58
  • @MattBall - Do I have an option? Change frequency is too low in my classes. Locking mechanism totally solves my issue as I don't have to dedicate a resource especially to merge different versions. – Ish Goel Jun 15 '13 at 14:02
  • 2
    If you have to "dedicate a resource especially to merge" then you're doing something horribly wrong. What you're asking to do is pretty much the exact opposite of how managing source code (doing it well, anyway) has been working for the past decade. – alroc Jun 16 '13 at 12:41
  • @KlasMellbourn git is a file storage with vcs features. ^_^ – bahrep Jun 17 '13 at 10:24

2 Answers2

4

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!

Community
  • 1
  • 1
mounds
  • 1,303
  • 12
  • 11
  • 1
    +1 I would also add that TFS behaves in much the same way, you can configure a Team Project to use pessimistic locking, but it's not recommended. The merge tools in TFS 2012 are pretty good and you can plug in your merge tool of choice if they aren't sufficient – James Reed Jun 17 '13 at 15:36
  • Thanks James, I've not used TFS myself so some good extra info. – mounds Jun 17 '13 at 22:27
  • @mounds - Thanks for the detailed reply. You along with other pros have convinced me to Embrace Merge! Although I am still weighing TFS! Thanks again – Ish Goel Jun 18 '13 at 10:46
  • Good to hear - and since you won't need locking, i'd recommend using git or hg. – mounds Jun 18 '13 at 22:02
1

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.

bahrep
  • 29,961
  • 12
  • 103
  • 150
  • Thanks for your reply. I selected @mounds as the best answer because of the details and clarity. Thanks again! – Ish Goel Jun 18 '13 at 10:48