Interview with Tom Lord of Arch Revision System 334
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."
Glad to see.... (Score:5, Informative)
* 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.
Change is good... (Score:3, Informative)
PCB@!
zero (Score:4, Informative)
Re:All that and he doesn't explain... (Score:5, Informative)
from: http://web.mit.edu/ghudson/info/fsfs/ [mit.edu]
"FSFS" is the name of a Subversion filesystem implementation, an
alternative to the original Berkeley DB-based implementation. See
http://subversion.tigris.org/ [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."
Re:Argument by Slashdot(r) ? (Score:2, Informative)
This actually convinced me to read the linked article.
I'm not even half way through and I'm already laughing!
Re:I don't like CVS, Subversion, or Arch (Score:2, Informative)
And of course is decentralised like arch.
Darcs [abridgegame.org]
Darcs wiki [scannedinavian.org]
Getting started with darcs in 5 steps [scannedinavian.org]
Re:I don't like CVS, Subversion, or Arch (Score:5, Informative)
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.
Arch is great--it's real weaknesses (Score:3, Informative)
I've been using arch for a while now. It's true that some of the setup is "too difficult"--it discourages adoption, but really, the documentation is quite good and example-laden.
I think the two real weaknesses of Arch are (and neither of these are showstoppers for me and well worth the Arch-y goodness):
arch is... (Score:5, Informative)
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.
Re:All that and he doesn't explain... (Score:5, Informative)
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 [tigris.org], 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...
agreed, Arch needs a better advocate (Score:3, Informative)
The last straw for me was Mr. Lord's attacks on Subversion, which seemed unhelpful to say the least; wheras the cogent response by Mr. Greg Hudson was a model of respectable behavior.
After several months of near-constant use of Subversion -- I love it, it's a joy to work with. It has a number of quibbles, but then again, dont we all?
kudos Subversion team!
I hope the Arch tool comes along, we can never have too many *different* tools, but I cant imagine how much better it would have to be before even contemplating switching from Svn.
Re:Where are the screenshots? (Score:3, Informative)
dcop kwin default setCurrentDesktop 4
for example, and watch your desktop switch. Every app exports actions (checkmail, go to URL etc.)
Re:arch is... (Score:3, Informative)
The specific problems that are mentioned. If you have 2 branches, mine and yours. They are similar, but we've both been hacking on them.
I merge you changes, and you merge mine, and then we both commit. This causes some conflicts later. If, on the other hand, I merge your changes, commit, and then you merge my changes and commit, everything works very well.
The above poster was a little bit extra scary in this regard. 90% of the time star-merge just works, and it is a tool that nobody else comes close to supporting (perhaps darcs, maybe monotone, I'm talking SVN and CVS primarily)
I use star-merge all the time. I'm very happy with it.
Re:Arch is great--it's real weaknesses (Score:2, Informative)
Re:I'm left out... (Score:5, Informative)
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
Arch is a no go (Score:5, Informative)
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.
Comment removed (Score:2, Informative)
Re:Does he know ANYTHING about Subversion? (Score:3, Informative)
I'm using Subversion now, have been for about 6 months, and it's IN EVERY WAY better than CVS, EXCEPT for industry adoption.
TL needs to spend some time on Arch marketing. What exactly is bad about Subversion? Give me an example scenario that shows me just how fucked I would be with svn and how Arch would ride in on a white horse and save the day. Then give me four or five more. Write a couple of whitepapers explaining how Arch is fundamentally much better than Subversion in its theoretical design and how that's going to save my project lots of time that we're wasting with Subversion. Otherwise I'm just going to assume that learning Arch is a waste of time because it's not any better, just different, and exists just because TL wanted to write his own VC system.
BTW, we just did a big branch and merge on my project. Not a big deal. Maybe with 100+ developers, Arch would rock Subversion's world, but how am I supposed to know that? It's not my responsibility to research every product out there just so I can find out whether needs I don't have are better filled by a different product than the one I'm using. That's the product/project evangelist's job.
No points are awarded for "it's totally different and strange, so you'll have to spend a lot of time learning it, and it's really slow, but it's way better than that other crap, because I say so."
Re:All that and he doesn't explain... (Score:3, Informative)
http://www.gnuarch.org/arch-overview.html
http://www.gnuarch.org/arch-tech.html
That tells how arch works. It would have taken too long in that interview for him to explain everything. But here is what you need to know:
Arch is a revision control system the only tools you need is:
* tar
* patch
* diff
* diff3
Thats it. Anything those tools can do you can do. Remember this when years down the road, arch or whatever is gone and you need to recover some old archive. Use those tools above and you can get it all back. Compare that with the proprietary solutions.
sri
Re:Most polar? (Score:2, Informative)
I guess I'm bipolar then, because I love and hate it.
As others have pointed out, the things Clearcase does well, it does really really well, and it probably does more things well than any other revision control system (certainly more than any revision control system I've used). I frankly think MVFS (the multiversion file system) is the closest thing to magic that I've ever seen in a piece of software; and in general, the things you need to do routinely as a developer are done so transparently and naturally that it's just amazing.
But the things it doesn't do well, it does horrendously. Performance is always a problem (and no matter how carefully you tune your network structure, someone will come along and make a small change and everything falls apart), minor server hiccups can lead to agonizing VOB rebuilds (we used to call this "a Clearcase holiday" at the first place I worked where Clearcase was in use), and the things you don't need to do routinely as a developer (but may have to do routinely as an administrator) can be arcane beyond belief.
After my first work experience with Clearcase, I jokingly told the folks at the next place I went to that I'd only work for them on condition that they wouldn't use Clearcase. They used Source Safe.
It took about four weeks of Source Safe for me to start begging them to consider switching to Clearcase.
The astonishingly high price of Clearcase has side effects that I'm not sure the folks at Rational truly understand (or understood; now it's IBM's turn to misunderstand it). The company I work for now (not the one mentioned previously) also uses Clearcase, and Multisite too. We are stuck with a 4-year out of date version of Clearcase (despite serious bugs and deficiencies) because the cost of incremental upgrades was way too high, and now that it's pretty clear we're going to have to migrate to the latest version, we still can't because of the difficulty of skipping so many revisions. If Rational's business model weren't to hold their customers upside down by the ankles and shake them until money stopped falling out, they might have actually had a more constant revenue stream.
Re:Please, someone, just reimplement Perforce (Score:4, Informative)
arch good for branching, bad for development (Score:4, Informative)
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.
Re:Arch is a no go (Score:5, Informative)
Set "untagged-source precious" in the tagging-methods file. Yes, the default sucks for some people, but arch will work either way.
More like it is the easy way out of a lot of the tricky details with file renames and removals for the arch developers.
Erm, no, now you're just showing your cluelessness. Encouraging out-of-tree builds has nothing at all to do with renames, moves, or any other version control feature. If you build in tree, you will have NO problems at all with any of the things you mention here.
There's no Windows/OS X integration or even clients.
tla runs fine on OS X, as long as you have GNU diff, tar and patch. The windows port is seems to be working fine, albeit slowly. For all the whining about the lack of a Windows port, there's amazingly few actual contributors.
For "integration", I assume you mean something like Tortoise{SVN,CVS}? Indeed, no one has written one of them yet.
Re:I'm left out... (Score:2, Informative)
Re:Subversion doesn't support "obliterate" (Score:3, Informative)
Re:darcs (Score:3, Informative)
Bitkeeper (last I looked) requires the user to explicitly mark files as "edited" -- obviously this makes diffs quicker, but it's a bit annoying and error prone. To my mind it's an overoptimization.
FreeBSD hackers user Perforce (Score:3, Informative)