Back to Blog home

Sourcecode collaboration

Published on Sunday March 30, 2008 by Thomas Zander in Qt News KDE | Comments

Programming in groups requires you to use a source revision system. Its a fact; not doing it would be like crossing the north pole in your sunday clothes, it won't be very successful. This shows; as long as people have collaborated in writing software, there have been systems to support this. I count 32 such systems on wikipedia .
Up until 2001 or so I used cvs exclusively. It did the job, more or less without loosing too much work. I started looking into distributed source revision systems, which looked a really cool idea that may give each individual programmer a lot more control over how he works, and how he can collaborate with his peers.
I went through TLA, got frustrated by the complexity, searched on and found Darcs. Fell in love quite quickly. Great idea, even better user interface. Unfortunately written in a language I never had the patience to go out an learn (haskell). Perfect romance setting, gives me what I need and I can never hope to fully understand it ;)

Darcs was started initially with the idea that a distributed system doesn't have to be more complex to use, just different from a centralized system. I have been part of the development of Darcs to the extend of working on user interface issues, writing clear language in the UI and other simple things like that.
Darcs has its share of technical problem, though. It doesn’t scale up well. Its basically unusable for bigger projects.

Flash back to the present. It feels like git is going to be the winner in this battle of programmer mindshare; on a technical level it certainly is the best there is. It scales up without effort and it is incredibly fast. Here at Trolltech various people are already using it every day. There is ongoing research to make it the default system in KDE as well.
Git, in my eyes, is the absolute opposite from Darcs, where one is bad the other rocks and vice versa. Git is technically superior; its basically the next generation in its field. Its got more features then you can wave a stick at, and its got mindshare and active development. The bad is that its reinvented the user interface, the in-line documentation is weak. The choice of command names arcane and inconsistent. Discoverability of features is basically a hit-and-miss.
Darcs, on the other hand, has not been strong technically but it has been developing a user interface (command line) over the last 4 years that is coherent+consistent, easy to learn, has lots of textual feedback while still being very feature rich.

Now, what to do! I like parts of both, but using either gives me headaces. The sum of the parts is a negative number in this case :)

So, like any good hacker, I started a new project to marry the two components. My project, which I call ‘VNG’ uses a normal git repository and expects git to be installed but using ‘vng’ you will find an interface designed much more coherently. Darcs users will feel right at home.
The project is very much in alpha right now; what is there works, but you’ll be using git for more advanced things. (and some not so advanced things).
I did find it time to make a nice announcement and call for developers that want to help out work on vng.

A short tutorial to get you started;

  $ mkdir ~/myproject
$ cd ~/myproject
$ vng init

You now have a Vng repository! Let's do something with it:

    $ touch myfile
$ vng add *
$ vng record -am "Initial import."
Finished recording patch `Initial import.'

A simple ‘vng’ will give you the help output, which I’ll just paste here as a good overview what I already have;

Usage: vng COMMAND ...

vng version 0.22 (>2008-03-28)
Commands:
help Display help for vng or a single commands.
Changing and querying the working copy:
add Add one or more new files or directories.
revert Revert to the recorded version (safe the first time only).
unrevert Undo the last revert (may fail if changes after the revert).
whatsnew Display unrecorded changes in the working copy.
Copying changes between the working copy and the repository:
record Save changes in the working copy to the repository as a patch.
unrecord Remove recorded patches without changing the working copy.
Copying patches between repositories with working copy update:
push Copy and apply patches from this repository to another one.
Administrating repositories:
initialize Initialize a new source tree as a vng repository.

Want to help or try vng? The sources are on; http://repo.or.cz/w/vng.git
Either send me patches or upload them to the 'mob' branch (which requires no password) on repo.

Looking forward to your flames! :)

Subscribe to Our Blog

Stay up to date with the latest marketing, sales and service tips and news.

We are updating our comment system and you could face some issues. Please write to us at feedback@qt.io to report issues/bugs.