home :: software :: vcs

Thu, 16 Mar 2006

Back down on the (VCS) farm

Interesting how Sun have also come to the same conclusion[1] as I have with respect to Distributed SCMs. Only bazaar, git and mercurial matter.

Also interesting is that for immediate targets they also recommend Subversion. Maybe I've been channeling Bill Joy or something? Anyway, earlier I couldn't decide which of the three to use.

Now I know that git is the way forward. The (multiple) interfaces help enourmously (cogito, git, StGit, P(atchy)g, etc.). It means if you have some funky interface, you can migrate slowly by reimplementing what you use with git plumbing.

Just as Carl Worth talks about reimplementing Hg using git. Another major factor is the culture on the mailing list(s). List culture encourages/discourages other participants. And the git list culture encourages lots of people to share very small changes.

Which has meant that git has caught up very quickly and eclipsed everything out there[2]. It really is odd reading that email and seeing just how far git has come.

Anyway it looks like what Sun are considering doing is that they might reimplement the interface of their internal tool (teamware) on top of git. If they can make that available, it'll advance things for everyone (again).

[ / software / vcs] Trackbacks (0) Comments (0) permanent link permanent link

Tue, 17 Jan 2006

Old McDonald had a version control system …

The great thing about standards is that there are so many to choose from

The same, of course, goes for VCS. I've used RCS, CVS, Subversion (svn), Arch (larch, tla and baz), Mercurial (hg), git, Bazaar-NG (bzr), svk and no doubt a few others I've forgotten, or wished I had.

The current state of the art in Free Software is Subversion IF you have to interoperate with developers who use Windows. That's it. Don't read further if you have Windows-based colleagues.

If, though, you get to choose the technology, then based on my experience with all of the above you then you should pick between: git, hg and/or bzr.

None of RCS, CVS nor svn are useful in the long-term since they do not allow for distributed development and branching. Yes, it can be done — a good example is svk — but not without difficulty and lots of gnashing of teeth. In svk's case, you need to be careful when merging since svn (which is what svk uses underneath) does not keep history or context.

I hit onto Arch and was lucky enough to stumble upon Robert Collins who guided my understanding of it and changesets. Unfortunately Arch was led by Tom Lord, who has real issues with generating a community of people around him. His first effort (larch), stagnated was re-written (by Robert) in C++, and called barch, while he wrote tla.

tla development also stagnated and, eventually, Canonical forked it and called it baz. I was very skeptical about a company like Canonical sticking to their promise ("we'll develop it until version 1.5 where it should be a good transition point to our next system"). I wasn't surprised when they renegged on that committment. It is their right of course, but it is a shame. Right now, if you have to use Arch — and you haven't used it before — use tla. If you have run into the limitations of tla, then use baz but bear in mind that baz is stone-cold dead as far as development is concerned. tla, is only cold dead.

Which brings us to bzr, hg and git. All three of these systems are very similiar.
Distributed development? Check.
Portable to everything (but Windows, and that is changing too)? Check.
Implement the same generic object-based filesystem? Check.

I've stayed away from bzr since Canonical is supporting it; that isn't bad but it does mean it'll forever be tied to what they want. It also means the community around it is extremely small. bzr is interesting in that it classifies everything as an object (directory, file, etc.) and stores them in pre-classified directories. In particular it stores file data in a 'weave' format (similiar to SCCS).

hg has a small, vibrant community around it but the problem is the community is small. And, like bzr, it also stores object in pre-classified direcoties – although in a delta-compressed format for space reasons. Both are written in Python (more about that latter) and have nice graphical tools to do things like quilt and three-way merges as well as visualising development history.

In the end I've chosen git as my future revision system; it has a development leader who encourages rather than discourages. The documentation overshadows everything except CVS and svns – and is on par with them. It is fast. it has a large community behind it. You can use it at a number of levels (git,cogito, stgit, etc.).

It has great support for importing to everything except bzr and I'm yet to find any particular issue with it. Plus it merging is very good. In fact, as Linus points out you can have any merging startegy you like. So, any theoretical advantages of hg and bzr are just that, theoretical.

[ / software / vcs] Trackbacks (0) Comments (0) permanent link permanent link

About

ॐ (aum) - what was, what is and what will be, wildfire's musings

Anand Kumria
wildfire@progsoc.org

Calendar

Topics

beauty - 1
blogging - 4
books - 1
comms - 1
debian - 7
django - 4
ebay - 1
edinburgh - 8
finance - 1
freedom - 2
general - 4
hardware - 3
dell - 2
disks - 1
health - 3
helsinki - 1
learning - 1
london - 1
review - 1
movies - 1
salsa - 1
security - 2
software - 22
blosxom - 2
gnome - 1
moblog - 1
ubuntu - 1
vcs - 2
zeroconf - 1
sydney - 8
isp - 3
thisisbroken - 2
travel - 1
work - 2
awayphone - 1
general - 1

Subscribe

Subscribe to a syndicated feed of my weblog, brought to you by the wonders of Atom.

Music

Blosxom

Rendered in only 0.2030 seconds.

ॐ (aum) - what was, what is and what will be