On Sun, Aug 10, 2003 at 04:43:19PM +0000, Faheem Mitha wrote: > On Fri, 08 Aug 2003 07:26:28 +0200, Xavier Maillard <zedek@gnu-rox.org> 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 <rweir@ertius.org> | mlspam@ertius.org | Do I look like I want a CC? Words of the day: Ron Brown Cohiba RSA Firewalls TWA Cocaine Rubin USCOI
Attachment:
pgpfzH1XmT5jr.pgp
Description: PGP signature