On Sun, Aug 10, 2003 at 04:43:19PM +0000, Faheem Mitha wrote: > On Fri, 08 Aug 2003 07:26:28 +0200, Xavier Maillard <[EMAIL PROTECTED]> wrote: > > > Since ages, I wanted to replace CVS here. > > > > I firstly tried to find out all the most interesting candidates for > > this. I have now a list of 2 items: subversion and tla. > > > > I tried to setup tla but didn't achieve totally this task. > > > > So now I am facing a dilemna: what is the most appropriate software to > > finally replace my old CVS (which hasn't satisfied me) ? > > > > For the little I tried tla, it seems smaller and easier to setup but as > > I didn't try at all subversion, this may be wrong. > > > > So I claim your help in making my choice: what would you use to replace > > CVS ? Subversion claims to be the CVS replacement but tla seems also > > interesting to me. > > > > Does anybody have feedback/recommendations for the 2 solutions ? > By the way, does anyone here use tla?
I do, for a few things. I only discovered it after I'd been using
Subversion for a while, so perhaps I can provide some contrast to the
numerous svn-only users above.
> If so, care to summarise the
> advantages/differences between tla and subversion from your
> perspective?
Sure. The beautiful thing about arch is that it's designed around
sets of changesets. Think of a changeset as a super-patch, that
tracks file renames and symlinks and permissions. This opens up all
sorts of neat avenues. A repository is just a bunch of changeset
files and some meta-data, so you can host it over most any protocol
that lets you retrieve and write files, including HTTP, WebDAV, SFTP
and FTP. Different methods work together seamlessly; for instance, I
create my archives on a cheap-virtual-hosting server via SFTP, but
everyone else accesses them via HTTP.
Since you can move changesets around, you can move them between
branches. And archives. This doesn't sound too special, but it leads
to a large array of extremely interesting features:
I've done some work on tla itself. To do this, I create a branch of
the author's main archive on my local machine. Now I have a private
branch, completely separate to everyone else's. I can commit to it,
branch it, etc, all without interfering with anyone else's work or
archive. Note that I only need read access to someone else's
repository to branch it.
This isn't a special case; most of the people who have contributed to
arch have their own branches, and do all their work there. When you
have something ready for the "mainline" (a bit of a misnomer, since
it's just another branch, like any other, except that Tom actually
creates tarballs of it ;-), you just email a location to the list, and
anyone else can merge your changes into their tree. Easy.
In fact, I don't just have one branch for my work on tla, I have one
for each feature I'm working on. This means I can incrementally work
on them, bits at a time, while still producing `clean' changesets,
with a particular feature in each.
Another example of this distributed branch system: I now use tla for
my uni assignments and such. I have a local archive in my home
directory at uni, and another one at home. I'm on dialup at home, so
I'm often not connected to the Internet when I'm doing work. No
worry, I just have a local branch of all my assignments, and commit to
that. Next time I'm online, I just push my changes to my remote
mirror (on the same vhost as my arch one, so it's always online), and
can merge those changes into my uni archive next time I feel like it.
The important thing to remember here is that I can work on *either*
branch, at uni or home, separate to the other. If I go too long
without syncing them up, then merging might get difficult, but it's
still possible.
Mirroring is yet another neat feature. I have my local archive on
this very desktop, which I commit to. To make my work accessible to
others, I can just `push' my changes to my world-readable mirror at
the aforementioned vhost. This isn't complicated;
"tla push-mirror archive-name" does the whole mirroring process for me.
There are few methods for keeping track of files (which is important
when you might be renaming them), too. The default is to just require
you to use "tla move foo bar" so that arch can keep track of what
you've done with your files. Another option is the "tagline" method.
You embed a "tag" in the first (or last) few lines of your source
files of the form "arch-tag: foo bar baz", where "foo bar baz" is some
string. It can be whatever you want, but there seem to be two main
camps on it: one for "Rob Weir Wed Aug 13 20:59:36 EST 2003 foobar.c"
style tags, and one for the-output-of-uuidgen. Either way, arch scans
files for these tags, and remembers them, so you can just use normal
Unix "mv" and "cp" to move files. Just don't ever change those tags
:-)
Atomic commits are there, of course, but Subversion has them too.
File/directory renames as well.
Another, perhaps less useful feature is symlink versioning.
Subversion (and CVS) don't have this, and it's not targeted for
pre-1.0, either.
> In Colin Walter's online diary/weblog, he mentioned that
> he uses tla, which he prefers over subversion, but he didn't give any
> details. I've seen no signs of other Debian people using it. I looked
> at it briefly, but was a bit put off by the fact that it enforces such
> strict rules for naming things. Eg. archives have to start with an
> email address.
It doesn't *have* to be an email address. However, as I hope you now
appreciate, since arch is a global system, with anyone able to create
their own branches and archives, *some* method has to be used to
differentiate them. Since most everyone using arch has their own
email address, it's just a neat way to create unique names.
Of course, it's not all roses; there are plenty of things Subversion
has going for it.
Subversion has a *much* larger support base. It's developer (and
user) mailing lists are very high traffic. They have a few people
paid to hack on svn full-time.
The svn client is probably a fair bit faster than tla, since tla does
a full diff of each file to see if they've been changed. The
"timestamp-optimisation hack" is just some code that will (optionally)
consider a file unchanged if it's modification time has not changed
since the last commit. This is already somewhat ameliorated by "tla
commit --files" which lets you only commit changes to certain files.
Subversion is very similar to CVS, which makes it much easier to use
for people already accustomed to CVS. arch's learning curve is a fair
bit steeper, but there are a number of documentation efforts working
on flattening it.
Currently, binary files are represented in changesets as an original
and a modified copy, so this produces large changesets. Moving to
something like xdelta for binary files would massively cut sizes in
these cases.
The naming convention thing. People either love or hate the fact that
arch has pre-conceived ideas about which files should be allowed into
the repository. The defaults will puke on things like .o and .*
files, but these are easily changed. There is work being done on the
"tagging-method generalisation" which will eliminate this in the
near-ish future.
There's no real clear upgrade path from CVS. Subversion has cvs2svn,
which is undergoing heavy development and is almost there for branches
and tags (mainline conversions have been possible for a while). There
is a project called cscvs which is working on extracting changesets
from CVS repositories (which is harder than it sounds, since CVS
doesn't track changes to groups of files.
Either one will suit a large range of users. They're both certainly
worth a look, and can handle the simple projects most people use
version control for. So, give both a chance, and see which ones you
like. I'm sure both will have fans for a long time to come.
Adios,
Rob Weir
--
Rob Weir <[EMAIL PROTECTED]> | [EMAIL PROTECTED] | Do I look like I want a CC?
Words of the day: Ron Brown Cohiba RSA Firewalls TWA Cocaine Rubin USCOI
pgp00000.pgp
Description: PGP signature
