Slashdot Mirror
Interview with Tom Lord of Arch Revision System
comforteagle writes "Every revision control system has its supporters and detractors, but none is as polar as Arch. Either you hate it or think it is the best thing in revision control ever. Built more around what our beloved kernel hackers use (BK), Arch is definitely a departure from CVS and Subversion. I've interviewed Tom Lord, Arch's daddy, about the application, and he has some -ahem- interesting answers and opinions."
* Per Incident
* Subscription
* Deployment Services
* Custom Development
that they're considering starting Support services soon. As a Configuration Management guy at a fairly large company, one of the reasons major corporations choose commercial version control software (Rational ClearCase, etc) over the open source counterparts (CVS, etc) is primarily due to lack of formal support.
I'm all for open source and even dislike it when companies reject Linux because of "lack of support" (this is ofcourse changing with RedHat's efforts), but experience has taught me that not everybody in a large organization is a hacker and willing to figure out the intricacies incase something goes wrong. They'd rather pay for a service contract incase anything goes wrong.
And ofcourse, there's also the accountability angle (which I dislike) to it, when you're using the version control software to develop critical/huge amount of bread-and-butter software - companies want to be able to have someone to point fingers at incase something messes up.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
arch tutorial
As to svn backends... I think it is prudent to point out a false statement made by Lord.
. html
from: http://web.mit.edu/ghudson/info/fsfs/
"FSFS" is the name of a Subversion filesystem implementation, an
alternative to the original Berkeley DB-based implementation. See
http://subversion.tigris.org/ for information about Subversion. This
is a propaganda document for FSFS, to help people determine if they
should be interested in using it instead of the BDB filesystem.
and from http://subversion.tigris.org/svn_1.1_releasenotes
"Non-database repositories
It's now possible to create repositories that don't use a BerkeleyDB database. Instead, these new repositories store data in the ordinary filesystem. Because Subversion developers often refer to the repository as "The Filesystem", we have adopted the rather confusing habit of referring to these new repositories as "fsfs" repositories... that is, a Filesystem implementation that uses the OS filesystem to store data."
You want Darcs. http://abridgegame.org/darcs/.
.. hack hack ..
.. interactive questions about changes ..
Using it is as simple as:
darcs init <dir>
darcs add <file>
darcs record
Then you have the option of sending your changes to other repositories, since Darcs is distributed.
You can copy/upload them directly, pull them from the other side, or even email them.
Those who do not know the past are doomed to reimplement it, poorly.
The good things about arch is:
The first two are why I use arch. The bad things are
Oh yeah, the development has just sun-flared just when it had begun starting up again. A huge flame war (where Tom's primary contribution seemed to be "Grow up", "You're childish" and worse) arch is now without a release manager, and understandable nobody wants to take that role.
In short, arch has great promise, but needs some drastic changes.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
FYI you can also use Apache or subversions own server to host a network repository.
If you want a windows gui front end for SVN try TortoiseSVN, this integrates nicely with explorer and works pretty well.
I'd like a similar ability with Konqueror, but that's a long way down my to do list.
It'd also be nice to work out how to really handle the situation with working cross platform and case(in)sensitive file names...
I hereby inform you that I have NOT been required to provide any decryption keys.
I used Bitkeeper for about two weeks, before being told that since I'd said this on the arch list: "I'd cringe if I had to use Bitkeeper", and because of my public pro-stance on free software (as they had researched from my homepage - http://www.souldound.net/), I was on their shitlist and they would not sell me, and therefore the company I currently work for, a license to use Bitkeeper.
Needless to say, I found this a little confronting, took stock of my temporary moral slip in even considering the use of proprietary software (forgive me Free Software gods), and promptly got stuck into arch/tla, which I've now been using for about a month.
In my experience, tla is more flexible - the design really does reach high, although the learning curve (at the moment at least) is a little higher for sure - you really do have to go read the tutorial, wiki, etc. I found the people on the gnu-arch-users@gnu.org mailing list to be very helpful though - even if personal/ power tiffs were going on, those involved never ceased to be supportive in replying to my questions.
Hope that's a useful datapoint,
Zenaan
* The Humble Legend * Debian Enterprise: http://debian-enterprise.org/ * Homepage: http://soulsound.net/ * PGP Key: h
Arch just isn't a viable alternative for me or my team.
1) It overestimates its own importance. It's just a version control system, yet it imposes restrictions on your coding practices. Specifically, you have to do out of tree builds or constant distcleans because arch assumes every file that gets created should be checked in, meaning there's a 1:1 mapping between the checkout directory and the repository by default. There's some work arounds, but it's a user-hostile stance to take and people moving from CVS/SVN will not accept this.
2) The reason for the above is because "it's a feature of arch to encourage separation of source from builds". More like it is the easy way out of a lot of the tricky details with file renames and removals for the arch developers. Shit, why don't you just solve the tabs-or-spaces problem while you're at it, only allow checkings following the One True Way (tabs btw). I encourage Tom Lord to try separation of head from ass before he starts worrying about the cleanliness of my build tree.
3) Tom Lord reminds me of a certain David Dawes (of Xfree86.org). It's just not that I personally don't like the guy, I could never commit my business or even hobby project to something lead by this man for the long term because I think the project has a high probability of self destructing.
4) It's just unprofessional to blast the SVN developers. Newflash for you Tom: It doesn't matter if Arch is twice as good technically, SVN is good enough, familiar to CVS users and easy to use. They're all perfectly good reasons to go with SVN over arch, it's the reason MySQL is more popular than PostgreSQL. You don't see Postgres developers heckling MySQL, and Postgres is never, ever, going to overtake MySQL. Just be content with making the best versioning system, never mind what everyone else does.
5) There's no Windows/OS X integration or even clients. That makes it a non-contender for any mixed environment, i.e. almost everywhere not counting projects being done in parent's basements.
It's like deja vu all over again.
I like Perforce, too, but it does have some bad points. First the good stuff: the commands are extremely intuitive, the branching and merging model kicks CVS butt, it has atomic commits, and at least for small organizations, it's quite fast. The bad points are: - There is no equivalent of a ".cvsignore" file, so it is hard to figure out what you need to "p4 add". I really like the ability to run "cvs update" and see what I've changed and what files I need to add. You can of course write a shell script to do figure this out. However, it is handy to have it built into the application, and since it seems like a pretty simple feature to implement, I really don't know why the Perforce developers haven't bothered. - Perforce is designed to help you avoid having two developers working on the same file at the same time. The idea is that you "p4 edit" each file before starting to make changes and get an (advisory) message if someone else has already done this. This is not a bad idea, but sometimes you have a project and very often you have a branch where there is only one developer, or where this is otherwise unnecessary. Having to "p4 edit" all the right things before submitting is kind of annoying at times, even though there is a command to find all such files for you. In general, I prefer the CVS model, where you just edit things and check them in, though I realize there are times when the explicity edit model is preferable. - Quite a bit of the processing happens on the server side, I think, so you can need a big server if you have a lot of developers. I worked in one environment, with several hundred developers, where performance was an issue. And of course, - It's not F/OSS, some of the data files are stored in a proprietary binary format, and you have to pay for it. On the other hand, compared to Clearcase or Bitkeeper... it's cheap. Nonwithstanding the bad points, the branching and merging support was enough to make me talk my boss into springing for it. At that time, Subversion was not far enough along that I felt comfortable relying on it for production (and I don't think it had a Windows client either, not sure if it does now, which was a requirement for one of our developers).
I have been using arch for several months, moving completely over from CVS. Yeah, it fixes some of the stuff in cvs like moving directories and files. Its concept of branching isn't bad either. However, it completely fails simple things that cvs (and probably subversion) accomplishes with easy, like querying the differences between two branches without checking either out (the recommended solution is to check both out and perform diffs between them).
There are other anomolies, like three different ways to update and/or merge branches, "update", "replay" and "star-merge". One version would be sufficient, with options which affect clobbering, etc.
Other problems are the fact that it has to detect changes it frequently has to rebuild itself from branches back, which can tain several minutes as it goes through about 150 patch revisions. Of course, you can create a revision library to overcome this (I think).
Don't get me wrong . . . I think that arch has the potential to be a great repository tool. Most of its problems could be overcome by simply automating sane defaults and allowing LESS choice. Currently, though, if I had to do merge my code over again, I would recommend against using it.