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

Question

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

Answer 1

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.

Answer 2

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.