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!
15 Responses to “Sourcecode collaboration”
I’m not sure if you can already declare Git the winner in this “battle”, Mercurial still seems a strong “opponent”, it certainly is the one I prefer. What Linus has done with Git is to bring distributed version control systems to the public eye, at least for the multitude of FLOSS developers who else might never have thought about changing away from CVS (or onyl to something very similar like Subversion). Although I imagine for lots of other developers is more like a coming home, I remeber using SCCS in university but afterwards in “the real world” no company seemed to use it. But now that Linus has made Git I can actually suggest using something like it at work, because suddenly people have heard and thought about this new-fangled distributed way of working. Pretty funny.
Nice project!
ooooh, unrevert. that would help me; I have a bad habit of forgetting about changes and thinking I can just revert stuff that’s actually important.
jesus … one more fork/addon/whatever out there … as if there were not enough of them
and then you’ll be busy doing other things but maintaining it and it will die at v0.2
how boring
Just a couple of code comments:
1. If you want to do heavy-lifting using the command line, I recommend the Boost.ProgramOptions library at http://boost.org/doc/libs/1_35_0/doc/html/program_options.html
2. You will make things easier on yourself if you programmatically format the help description strings to the width you want, rather than constantly re-format them inline, in your printExtendedHelp function.
Excellent initiative! I’m using darcs and am really fond of it, but of course doesn’t like its scalability problems. Having git with the darcs interface will be superb!
Thx
What about Bazaar?
have you checked gitorious(opensource)/github? they are very nice projects, take a look:
http://gitorious.org
http://github.com
@K00nj and @david. I think you missed the point, git is in use a lot around me and I need a command line interface for it that is better then the default. That is what this project is about. Not about bazaar/mercurial/whatever and not about hosting sites.
To the rest; thanks for the support
In response to the above comment about boost::program_options… I’ve got experience with it and it’s fairly nice but I’ve found its API a little… odd, to say the least. I’ve been working on a QtCore-based command-line parser in the same vein as boost::po but simpler; it doesn’t have quite the same level of functionality but it produces much more readable code in my opinion. If anyone’s interested in looking at it, the current SVN of Qxt (libqxt.org) has QxtCommandOptions.
@Adam: I agree the syntax of program options is unusual, but it is easy to become familiar with, and the library has the advantage of handling practically every anomaly in command-line processing you might encounter (as well as being quite usable in ‘normal’ situations).
OTOH, your library certainly looks like it captures the basics in a very readable way. However, I do not like the repetition of the command name in the add() and alias() calls - maybe it would be better to offer a overload of add() accepting a QPair, like this:
options.add(qMakePair(”compress”, “c”), “create a new archive”);
options.add(qMakePair(”extract”, “x”), “extract files from an archive”);
or more generally, a QStringList?
options.add(QStringList()
Have you tried Mercurial? I think it fits the “get it done” spirit of Qt much better than git
I’m a *big* fan of DVCS. I’ve used most of the modern systems at this point (Bazaar, Mercurial, Darcs, Git), and while they’ve all got their weaknesses I’ve enjoyed using them all — except git. And the main reason is precisely what you’ve cited: that it’s user interface is very uneven, full of gotchas and hidden features. As Donald Norman famously said about Unix: “The trouble with it is the user interface is horrid” [1]. I certainly hope it’s not taking over all the developer mindshare for DVCSes because I can’t see that improving very easily: yes they make strides in this area, and the 1.5 generation is at least usable… but it’s still a real pain, and they have backward compatibility to worry about at least on some level. It puts me off getting too near any project that requires using it frequently.
[1] http://www.linux.org.uk/~dan/rumor/rumor.shrink
So I’ve often wondered, if their idea of “porcelains” and “plumbing” (i.e interfaces for the rest of us) is so great why *hasn’t* anyone written a better porcelain. I’ve not had the courage to try, particularly since there are alternatives and really good ones at that. The idea of using Darcs as the porcelain is inspired. I hope you get considerably past an 0.2, because git isn’t going anywhere and having some facility for using it that’s not bloody awful will be a real boon. I wish I had the time to help.
Until then I personally am sticking with Mercurial. And I will continue to warn people about jumping on the git bandwagon.
p.s. Your code is, in typical Qt fashion, lovely to read. It bodes very well for a UI centric project :).
> And I will continue to warn people about jumping on the git bandwagon.
Just to clarify: I’m not telling people “don’t use git”. I’m telling people: be aware of the cost. Don’t use it *just because* the Linux kernel people are using it. They have very different use cases than many people, and very will tolerate a complex interface in order to get more advanced (or subtle) features.