Handling multi-user work on Version Control Systems [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I can imagine system of how can multiple programmers work intensive on same codebase in same time.

• I think the Version Control System on server should be able to lock one file for editing when one of programmers connected to codebase starts editing it

• Live notification about changes in codebase and pushing updated files to others (via notification or automatic updating)

• Chatting about changesets on fly, showing commits and diffs (some integrated source history browser like Trac has or similar would be fine too)

• Solution integrated with some featured IDE (like Netbeans or Eclipse)

But what is some cheap (perfect would be open source) solution for this?

What systems have you tested and can recommend me to use?

Edit no.1:

Suggested solution doesn't have to provide all functions I wrote in question. That list is my imaginary list of what could this system have, not a requirements list. Question is more about how do you solve "multi-user work on svn/cvs/etc.." and what solution you like most.

Edit no.2

Little bit around @thiton comment

It is very important to point out that there exists something called RCS (Revision Control System). From what I know RSC is an ancestor of CV开发者_运维知识库S. CVS as a concept is implemented in svn, git, mercurial, bazaar, etc...

The reason why we moved from RSC to its successors, is that old way of doing things was slowing down and overcomplicating team work. Locking files and releasing them only after end of editing them, is not the way we want to go. Now as we can reverse changes on a single file (reverting it to given revision number) and so repair our or others faults, there is need for that.

So I striked out the first point on my list (note it's not written down in descending priority order), and thank @thiton to remind me that.

---

What you ask about is covered by Application Lifecycle Management (ALM) and the plenty of ALM toolkits. Examples of such toolkits:

1. Atlassian products: Jira (issue tracking), Fisheye (diff viewer/repository viewer), Crucible (code review tool) and others (Confluence, Bamboo, Clover). That's a stack of instruments I would recommend anybody facing issue you've described. I think I should not cover what Jira does, as long as it is probably the most popular issue tracking system. It is possible to get integration of issue tracking with version control using Subversion-Jira plugin. After this plugin has been installed and configured, it is allowed to mention issue number (#234, #687, etc) in commit comments. Jira then will show all the commits under specific issue as this commits have contributed to the issue. If you want to view the content of those commits, you will need Fisheye. It allows you not only to view, but also comment changes and put changesets in the form of links. There will be no problem with referencing to changeset or commit if you have Fisheye. Another level of collaboration is Crucible. It allows to perform code review of all the commits you have in version control system performed by other users. It is very flexible. For example, you can put a comment in front of specific source code line in the specific commit, create subtasks on the fly and put your own code into the review comment. Atlassian tools are the best tools money can buy, IMHO. As you might see, they are not free. And that's why you might not like it. There are alternatives, though.
2. ViewVC - repository browsing/diff viewer tool. Can be considered to be Fisheye replacement.
3. WebSVN - another repository browsing/diff viewer tool.
4. Commit Monitor. Not always you would like to be notified via email. In this case Commit Monitor (runs under Windows) might come in handy. It displays popup on the desktop when somebody makes a commit. From my point of view, it is more convenient then getting e-mails. Moreover, you can view the list of last commits directly in Commit Monitor. If you do not have possibility to run in on Windows, use Wine or Subversion Commit Monitor.
5. Use changelists. Both subversion and TortoiseSVN have changelist feature (it is not the same as changeset), and it often comes in handy. All you need to know about it is that changelists are similar to the concept of issue, but on the version-control level.

In addition to all the mentioned tools, I would recommend using following repository structure for subversion repository:

    /project
        /trunk
        /tags
            /builds
                /PA
                /A
                /B
            /releases
                /AR
                /BR
                /RC
                /ST
        /branches
            /experimental
            /maintenance
                /versions
                /platforms
            /releases

This repo structure is focused on following important aspects of version control:

1. Use branches
2. Always know why you need branches
3. Use tags
4. Always know why you need tags :)
5. Use svn:externals. It means that you should try to modularize your app and think about dependencies between modules.
6. Use 'repository per project' approach. It will help to modularize your app and avoid frequent mistakes.
7. Use continuous integration. It will help to track the current state of branches you have in your repository. Actually, continuous integration can be considered to have a huge effect on collaborative activities and team communication. If you didn't use continuous integration before and do not where to start, there are plenty of choices: CruiseControl (also CruiseControl.NET and CruiseControl.rb), Hudson, Jenkins, Bamboo, TeamCity, Continuum, etc.

I mentioned this repository structure because it help a lot when such convention exists:

1. Communication. You do not need to write a lot in commit logs in order to describe what you're doing - you just add corresponding artifact into the VCS.
2. Lower chances to make the wrong move. Very often developers urgently need something to do, but do not know exactly how to do this. That's the case when it is easy to make a wrong move, therefore raise necessity of communication and interaction with others. It helps a lot when list of such common moves (in terms of VCS) exists not somewhere on the wiki (where one should try to find), but right away in the repository.
3. Less questions. Having such structure in the repository in most cases is self-explanatory. It is better when there are less questions about how to do something in VCS.

---

You can do what you want with Subversion (svn). What I like for live notifications is an email sent after every commit with the diff of the change. This seams strange at first but as soon as you get used to it you miss it if it's not available.

Every developer has e-mail and knows how to handle it. If you do not want to be disturbed you simply close your mail client. It works with every tool since it runs on the server. You can find a tutorial on this Question.

I would not lock a file if one developer is editing it. In this case all other developers can't make their changes and everyone get slowed down. This happens quiet fast if you have long helper classes for your business logic.

And do not automatically update the working copy. If you are building your project or changing a file it leads easily to conflicts. In the best case you only have to build it again, but on the worst case you lost all your data since your last commit.

The hook script approach can be done also with git and mercurial, if you prefer a distributed version control system. In that case the hook runs on the repository you elected to be the master.

---

If you really want live updates in your working tree when others commit changes then you need something like ClearCase, but that's most decidedly not cheap (and I and most people I know hate it).

Otherwise, if you prefer to pull others' changes manually when you're ready for them, all the VCS you list in edit 2 will do email notifications (you need to write a hook script yourself, in most cases), and most have graphical interfaces that do diffs and what-not.

You haven't given enough info to decide which to recommend. You have to decide if you want centralized or distributed, and then beyond that it's really just a matter of taste. I'm not aware of any having integrated chat facilities, but hey, it's not hard to set up an IRC server, or just create a room on freenode (if you're not doing anything confidential).

SVN, Git, and Bazaar are all good options. I've not used Mercurial, but I've heard good things about it. Arch will work, but I don't like it. CVS will work, but something with changesets will make the history easier to understand (much) later.

Other VCS are available also.

---

There are multiple schools of thought regarding the use of version control systems.

My preference is to try to keep each upcoming feature worked in a separate feature branch (pretty much no matter how small). The person(s) assigned for this feature then only have their own changes to work on; no interference comes from the other developers.

Bug fixes (aside from truly trivial ones) also go first in as separate branches, just to keep the trunk line stable and clean. Latest trunk revision always corresponds to the last delivered version (release) of the product.

When a new release is being prepared, if there is only a single change coming, and that change itself is based on the previously delivered version, then the tests can be run against the branch version, and at time of new release, changes from the branch are simply integrated into the trunk version. Version control systems such as cvs and svn have decent support for this kinds of merge operations (I haven't been working with git myself, but understand that branches and merges are handled well there as well).

If there are several distinct changes to be integrated, I prefer to create a separate "integration" branch, to which I first collect one by one all the changes to be integrated. Again, the version control systems do flag when there are conflicting edits (i.e. two different changes in one place of a single code file). What they understandably cannot tell is if there are functional conflicts caused by several distinct changes. So at least some oversight, and prefrably also testing, will be needed after each integration.

Then, when all the individual changes have been integrated to the integration branch, it can be thoroughly tested, and again merged to the trunk when it is ready for release. If there are further corrections to be made, they can be developed further in the original feature branches, and then the corrections integrated agani to the integration branch.

This way lends itself very well to fast bug correction response, as the trunk always contains the last release. It also lends itself nicely to speculative development, as the distinct feature branches only affect the trunk line when integrated. Also, features can be worked over several release cycles, as releases do not affect the ongoing development in feature branches. This way the "bus factor" (what happens if one of the developers is run over by a bus) is also reduced; incomplete and even incompilable code can be checked in in the feature branches -- and all work done is available for other developers if for any reason someone is missing from work. Also, workstation disasters do not cause a significant worry, as would be if the workstation could easily hold one weeks worth of development work not checked in, not backed up.

Whether to update the long-lived feature branches always to latest releases as new releaases are made is a question of policy, and also may depend on what went in in the last release. Another question of policy is the ownership of the integration branch; whether there's some single person responsible for collecting all the feature branch changes and making the needed smal changes to make them fit with the other changes, or whether each feature developer/team will be responsible for getting the changes from that specific feature branch to the integration branch. I favor the separate "release builder" (who of course typically is one of the feature developers).

At least in my reality it seems that 3-4 devs can pretty well work in a single branch, if they otherwise communicate with each other (shared office space is the preferred way). They do organise their work themselves, and can avoid stepping on each others' toes. Also, the separate feature branches seem to rather seldom touch the same files with each other, so most of the merge cycles are rather painless (and the painful ones can be predicted by the change descriptions). On the other hand, even a single developer multi-taskng over several distinct but simultaneous change tasks will end up in trouble, if the changes are not isolated in branches.

So, in a summary: do not lock files, but instead have a good version control system, utilize branches bravely, and keep your eyes open when merging changes from branches.