Thu, 16 Mar 2006
Interesting how Sun have also come to the same conclusion 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. 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).
Tue, 17 Jan 2006
The great thing about standards is that there are so many to
The same, of course, goes for VCS. I've used
svn), Arch (
baz), Mercurial (
git, Bazaar-NG (
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.
you get to choose the technology, then based on my experience with all
of the above you then you should pick between:
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
svn (which is what
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
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
Which brings us to
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
three-way merges as well as visualising development history.
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
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
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
bzr are just
ॐ (aum) - what was, what is and what will be, wildfire's musings
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of Atom.
Rendered in only 0.2030 seconds.