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."
"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."
They forget those of us who have never heard of it before.
I'm probably at the karma cap. Mod up a funny troll instead, it lightens the mood
Interview with Tom, Lord of Arch Revision System
# cd /usr/srcr oot
# export CVSROOT=:pserver:anoncvs@cvs.gnuarch.org:/usr/cvs
# cvs login - the password is anoncvs.
# cvs checkout arch
This guy should go into politics! His brain-mouth cable has no filter on it. It'd be nice to hear politicians describe their colleagues' bills as "a horrible, horrible design based on a few very good ideas" or "clunky junk".
I'd love to hear his opinion on the vi/emacs debate... that'd get some heads rollin'!
Well, he slams the subversion design pretty good. I don't know anything about the design of subversion of either Arch or Subversion to comment on either - maybe someone else can, but subversion seems to be gaining quite a following from what I've seen.
Look at the way the Linux kernel project works, at least for developers who are willing to drink the koolaid of Bit Keeper (BK) licensing.
I guess that's a different koolaid than what the Stallman/Gnu cult members are drinking.
Either you hate it or think it is the best thing in revision control ever.
I hate it! God damnit! What was wrong with CVS? (that's a rhetorical question) It was so easy to just cvs co and cvs up.
Then there's some non-intuitive system that everyon and their dog wants to use.
Bah.
Bah I say!
I don't know anything about Mr. Lord's product, but I do know he sounds like a 12 year old boy when he writes. People might respect you and your work more if you use the word "blows" a little less, and spend less time lashing out at other products with such ferocity.
My sig is blank, I typed this by hand.
Is this a CVS problem or a NFS problem?
Either way, the solution is "don't run CVS over NFS". Use the client-server protocal - either ext or pserver.
The Army reading list
I'd love to have a Free, lightweight, distributed, reliable, easy to use revision control system.
CVS is Free and lightweight. I run it on my handheld with no problems.
Subversion is Free, reliable (so far), and very easy to use. In fact the stripped-down CVS-based CLI interface is just slightly different than CVS but much more productive.
Arch is all of the above.. EXCEPT easy to use. Here's the "eye-opener" that Mr. Lord really needs to address:
% svn --help | grep '^ ' | wc -l
28
% tla help | grep ' : ' | wc -l
105
I'm sorry but just watching that scroll by is enough to make me say "well, maybe I'll figure this out later". Which is what I do every time I look at Arch.
What I would like is a RCS that has the ease of use of Subversion, but uses changesets like Arch, and uses a lightweight storage system like Arch. I totally agree with his complaints about Subversion.. it is a bloated toy (using Berkeley DB for versioned tree storage is just the most bizarre decision). But the interface is the best, hands-down...
So.. where's the killer open source RCS?? Open source is supposed to be about good no-frills development tools!
GNU arch was awarded an Open Source Award last quarter.
As ever people OSI is accepting nominations for OSAs.
John.
I think the most polar source control system is Rational's ClearCase. You really love it or really hate. It's a very complex software package, but very powerful.
Personally, I really like ClearCase. Too bad its so expensive, otherwise I'd use it for all my open source work.
Does it integrate with the OS?
Which OS?
>Seriously, the last thing I want is another commandline POS where I have to remerber a ton of commands and switches.
Lord Vader, your revision control system is ready
> Does it integrate with the OS?
Mr Gates, how did you get such a low uid on Slashdot?
* 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
How can he say CVS is clunky junk?
I use it on my 486 SCO Unix machine and think it's the cat's meow.
I get worried when the first thing on the page for Arch is a short bio of Lord Developer. WTF? Just good code please, no large egos. 'nuff said.
I don't know how the fuck those links do that, but how the hell do I disable the ability of those sites to take over my browser like that?
Mozilla Firefox on Debian Linux
I use subversion and have been on the lists for a couple of years now. Tom Lord has been to those lists as well. In all those times, including this one, he has never explained how arch is better. For the lead developer to be unable to communicate the rasion d'etre for a project in a way that makes others curious is not a good thing.
Primarily, he has only flamed svn. Even this interview he talked more about svn than arch. Nothing he said raised any interest in me to look at arch.
Also, his criticism of svn's current backend was true 8 months ago. There is another backend that will be available soon. And with that, the sytem will be able to handle additonal backends in good form.
SVK, which Lord mentioned, is a feather in svn's hat since it uses subversion as a base. If distributed mode is a real need I would suggest looking at BK or svk.
Why would you want it to integrate with the OS? I can see integrating into an IDE but not into an OS.
while my company is stuck in CVS, Subversion is not going to be too big a jump. As the build manager I'm heading up the switch, and love the similarities, and the advantages of svn. I've installed/played with ARCH, however I've never gotten very comfortable with it. While I don't think it would be very hard to learn, there's certainly a learning curve that others will have to go through.
PCB@!
free ipod and free gmail!
arch tutorial
Tom Lord sounds like he got his argumentation skills by watching Beavis and Butthead, reading JeffK, and getting into flame wars with trolls on /.
Q: What's wrong with Subversion?
A: It sucks.
Q: What's wrong with CVS?
A: It sucks.
Q: Can you be more specific about Subversion?
A: Yes. Subversion is teh suck. I realize that's a little inflamatory, so let me say that the sky is blue, dogs are hairy, and Subversion is TEH SUCK, fagg0t!!11
Q: Can you be more specific about CVS?
A: Yes, allow me to be more specific. It sux0rs. Hard. CVS is teh sux0r.
Q: What's good about Arch?
A: It rules. Also, I have a large penis. Fagg0t.
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
Gabbo Gabbo Gabbo!
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
You smarmy prick. It's actually completely on-topic seeing as it's about the article in question. How else will Slashdot improve without some constructive critique.
don't we get enough marketing droids that can't ever say what they mean? I agree he was upfront, blunt, and brutal but in the end he didn't seem crazy or wild or unreasonable. He even backed up some of his more inflammatory statements. I think he was a very good interviewee. He did seem to be a little too forgiving to his project own weaknesses but that's is not unexpected and relatively forgiveable.
Your CPU is not doing anything else, at least do something.
No. The 'commandline POS' is very necessary - it's what runs underneath. I have no experience of Arch, but I do use Subversion - and if you want to use the GUI (say, on Windows) you use something like TortoiseSVN which integrates with Windows Explorer. However, advanced users may want to script some of their Subversion commands, or possibly just find it faster to use the command line than a GUI. Personally, I find Subversion pretty easy to use on the command line so I don't bother with a GUI - it gets in the way. I'm using Mac OSX right now - the epitome of a nice GUI, and whilst I use OSX's superb GUI for many things when it comes to my version control tools, I forgo the pretty GUI and just open a Terminal.
The main problemw ith a GUI is that you can't script them (or not trivially anyway). A development tool (which is largely what version control is) that cannot be scripted is useless. The GUI is not the be-all-and-end-all. This is what frustrates me so much about Windows on the server (and why it's not a very good server OS) - it's because many parts of Windows are totally unscriptable out of the box. Don't do this to our version control software too.
The GUI should be separate from the 'business logic' of any tool in any case - therefore there's absolutely nothing wrong with a GUI that drives command line tools underneath, or perhaps provides another interface by linking to a library which provides the heavy lifting parts of the code.
Oolite: Elite-like game. For Mac, Linux and Windows
Comment removed based on user account deletion
The guy tends to use strong words when describing the flaws of cvs/svn. However, he gives no details. There seems to be a lot of talk with little information.
Even if this arch thing is good, i am not going to switch for two reasons: i am happy with cvs, being aware of its drawbacks, switching to a better system is not critical; i am certainly not impressed by what its author says.
Perhaps i should have given them the other way around.
I thought this was the "don't checkout a sandbox on a shared drive" thing, not some problem in talking to the cvs server.
#!/usr/bin/english
Tom Lord has tried to work more closely with other revision control packages before (including the subversion team) but he has been hampered by his complete and total lack of people skills. I don't think he tries to, but he ends up offending everyone he tries to have a "discussion" with. Its comical and sad at the same time.
I have been smitten by your clever retorts and never again will I be able post without thinking of you looming over my messages, ready to strike at a moments notice. You sir are a champion of the idiots and I sincerely thank you for setting me straight. I'm sure now that nearly everyone gives a flying fuck about Tom Lord and his software magic.
Hm, maybe. But I think it's pretty much both - running CVS over NFS, whether by putting the local copy on an NFS drive or by using the local CVS protocol to access an NFS drive, is a bad idea.
:-)
Unfortunately I'm not enough of a guru to know who to blame it on - CVS or NFS - but I know how to avoid it
The Army reading list
Article summary: every decision made in the development of Subversion is an obvious mistake and a total failure - the result of naive programmers daring to disagree with the "Lord" of revision control.
When given the chance to talk about versioning systems, he spends more time bad-mouthing the competition than
he does promoting his own solution. Did one of the Subversion guys "steal" his girlfriend or something?
We also have some beginnings of arch GUIs. Here too I hope to see one of them mature and perhaps become distributed with Arch. One nice side effect of that is that it will clear a path for integrating arch with existing IDEs.
On the serious side, it will be nice when this is integrated with eclipse.
Ok, I admit I just want to get darcs mentioned here, but I really want to know what Tom (as well as Larry McVoy) thinks about darcs. In particular, whether the theory will stand up to real use and scale to large projects. I have a hunch that David Roundy has discovered much of what Larry McVoy said was a dozen PhD theses worth of research behind BitKeeper.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Subversion 1.1 has support for a normal filesystem backend instead of BerklyDB. See release notes.
It's now possible to create repositories that don't use a BerkeleyDB database. Instead, these new repositories store data in the ordinary filesystem.
if someone can tell me of such a tool which can handle filesystem ownerships and permissions (in the context of Linux, in my case), and version them, I would like to hear it.
At the moment I am using subversion because it has versioned properties and I wrote a bunch of scripts to extract filesystem metadata and create svn properties from them and vice versa.
We have at least one arch fanatic where I work and when I asked him about this, he seemed to think that using arch for what I want would be *fantastic* and arch would rule, only I'd have to use the cvs method of maintaining ownerships and permissions, ie a script which maintains them in a file which is in the repository. Which I tried and which sucks.
In the free world the media isn't government run; the government is media run.
Tom gets a lot of stuff right, but, like Mcvoy, he really wants the fact that certain things work well for the Linux kernel to imply that they will work well for projects in general. Sorry, but this ain't really true. Tools like BK and Arch obviously facilitate the way that the Linux kernel is developed, but most projects do not use the same kind of organization that the Linux kernel does, and would be much better off with different tools.
Having had experience with MKS and the idea of changesets (and being able to merge changeset across branches) this is VERY powerful. Tied with a tracking system, project management/config. management becomes greatly simplified. Regardless of how Arch does, hopefully it'll spur others to add more changeset features to their software as well.
funny cos it's true
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):
demi
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.
Look at the address of the link: www.google.com/url?sa=U&start=3&q=http://nyud.info
Then try `whois nyud.info`. All will become clear.
Just a minor correction:
The main problemw ith a GUI is that you can't script them (or not trivially anyway).
MacOS has a scripting language called AppleScript which lets you trivially script pretty much every GUI app that runs on the system. In OS X, they've made it so that for an app to NOT be scriptable, the developer of that app would have to do it on purpose.
So... just because Windows and Linux don't have a good solution to this problem doesn't mean that the problem applies to EVERY GUI.
Comment of the year
Computer, Arch!
Damn.
is just trying to protect his source of income.
Of course he's going to discourage anybody who wants to implement a SCM/VC system (by any means necessary, including the BK license). I mean why the hell would he encourage people to develop competitors to his system?
A quote from an email conversation with an unnamed Arch user in January: "I think Arch's biggest bug is the one up the developer's collective asses."
This article is a good example. Tom Lord just hand-waves his way past every question. Subversion sucks!!! CVS users are teh stupid!!! If he tones it down a bit, he definitely has a future in politics. But I don't think he's a very good software architect.
OK, it's true that CVS and Subversion have problems. But, gak, so does Arch. Good God is it slow for big projects (something they've been promising to fix for years). And it's got some horrifying naming conventions: "tla--devo--1.3". And the files! "{arch}", "++default-version", ",,inode-sigs". Whatever Lord was smoking, it must have been good. The branching and merging operators are powerful but, thanks to all the punctuantion, they are also ugly. It's like the entire UI goes out of its way to be downright unfriendly.
Every time someone mentions these deficiencies on the mailing list, they just get flamed for not truly understanding Arch. "Namespaces! Namespaces! Namespaces!" "Win32 is for lusrs!" Whatever. I just want a tool that helps me get the job done.
Personally, I'm in the middle of transitioning to Subversion. It's better than CVS, and it is faster and nicer to use than Arch. Works for me.
What struck me as interesting about his comments is he only admitted to one flaw in Arch and he sort of mumbled it out: "...performance...won't bother most users...yadda, yadda, yadda".
I find it hard to believe that Arch would be so perfect. If he really knew the strength of his software he would also have no problem admitting to its weaknesses and Arch would be that much better for it.
Instead he spent most of the article attacking Subversion. If Arch is really that good, why would he spend so much time complaining and critiquing something else?
These are all known issues under development (I wish I had time to help resolve them), and I'll try arch again in a while.
As is frequently pointed out, arch is also very different than CVS.
I really, really wanted to try 'arch' but failed. I was up and productive with Subversion in about 20 minutes. The very clear and comprehensive PDF book on Svn has been well-used.
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.
I'd be interested to hear if anyone has actually gotten happy with distributed development under arch. I tried a reasonably simple case a few weeks ago, and couldn't get it to feel right.
What I was trying to do was to have a two-layer revision control system, where I have a private archive in addition to the project archive, and I check into the private one all the time, and transfer changesets to the project archive when I'm happy with it. That way, I can be halfway through refactoring a big chunk of code, have it completely broken, but have the work so far revision controlled so that, if I accidentally wipe out my build tree, I can recover it.
The problem I ran into was that I couldn't get the two archives to agree exactly on the current status: whenever I transferred my changes up from the private archive, it added a log message to the project archive, and my private archive wasn't up to date, because it didn't have the message. When I updated my private archive from the project archive (either to pick up the message or to get other people's changes), I had to put in a log message, which the project archive then didn't have.
It seems like arch really ought to support getting two archives in perfect sync, as well as disregarding a commit to a remote archive that only adds changesets already in the local archive (as well as disregarding the changesets themselves, which it does do).
Although this is an Arch thread, after these rantings by Tom Lord (geeze does he really need to bash other projects without any serious explanation every time he gives an interview) For the wonderful CVS replacement they made. I used SVN for half a year in my last job, and the thing never gave me any serious trouble. From the day it reached 1.0 there was at least a basic integration support there, and the mailing lists are well moderated. Thanks Subversion team for the excellent program you delivered, you dont deserve Tom Lords constant bashing. But back to Arch, everybody knows it is a good program, all it needs is better tool integration. The problem has been existing for years.
KDE has dcop. Type this at the command line in KDE:
dcop kwin default setCurrentDesktop 4
for example, and watch your desktop switch. Every app exports actions (checkmail, go to URL etc.)
Do any of these systems have good support for automatic conflict-resolution? While we don't run into conflicts often, their annoyance is compounded by the obviousness of their resolution (that is, yes, it's easy for us to fix, but why should we have to?) We're still using CVS (oh, stop laughing already) ... does anything else have support for (and preferably already-implemented) rules to auto-resolve conflicts?
The BDB backend has it's problems (though none of them nearly as drastic as he seems to think), but has he really never heard of the FSFS backend?
The rest of the criticism is so vague that it kinda makes it hard to reply to: "it takes too many steps backward in various areas", oh, "various areas" - of course! I've been noticing that.
I'm in the process of moving to Subversion from CVS (which I agree is deeply broken, by todays standards), and I've yet to encounter a single thing that Subversion is worse at than CVS. And a hell of a lot of things that it does much, much better.
Now if that interview presented the tiniest bit of information about what arch does differently (apart from, you know, not being "teh suck") I would be tempted to check it out.
sic transit gloria mundi
MacOS has a scripting language called AppleScript which lets you trivially script pretty much every GUI app that runs on the system. In OS X, they've made it so that for an app to NOT be scriptable, the developer of that app would have to do it on purpose.
So... just because Windows and Linux don't have a good solution to this problem doesn't mean that the problem applies to EVERY GUI.
AppleScript does the job, but it's often incomprehensibly slow. Windows DCOM and gnome/kde also give you similar scriptability, but those interfaces are not made for easy use on the command line. What we want is for someone to have given serious thought to making the CLI simple and easy to use.
So.. where's the killer open source RCS?? Open source is supposed to be about good no-frills development tools!
Download Eclipse and the CVS plugin.
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 got interested in that project awhile back as I felt that daily version control is really holding back my project development. Unfortunately at the time arch was not Win32 ready (is it now?) and my Windows mindset coworkers already categorized CVS as "piece of shit" compared to MS Visual Sourcesafe (so there was no place to start that debate again). I think that the quest for an intuitive (for all user levels), revolutionary (merging of forked projects or selectively applying patches is difficult), Free (as in freedom, but also as in corporate PHB show me the money), stable (is it a one-man egotrip or really value-added? what's the story with the restraining order? (I'll burn for that, especially today)) and popular (is there a place for new players in the version control market? Was that interview and the slashdot followup really such a good PR?) Is still on.
IMO, svn's use of berkeley DB as its backend, an opaque, non-human-readable, non-human-recoverable, non-machine-portable* database, is its biggest shortcoming...
I still use svn, though. I'm just glad to be able to rename directories.
I'd pee myself if someone forked svn and gave it a more friendly backend.
-Ed
*By this, I mean that you can't take the berkeley DB, copy it to another machine, and expect it to work... the internal byte order is machine specific.
Arch scales well? You kidding, don't you? Or maybe, yes if you drop a cacherev every 10 patchsets. Ever tried it on Windows? No? Well, do yourself a favour, don't do it. Arch copied BK functionalities, implementing them in a really bad way. OTOH BK license sucks, and all other open source VS systems that enable distributed development and decent merging capabilities, suck.
why no talk about perforce and good old p4?
not free, but very nice
Just read some of the Arch whitepaper, and saw how it stores a file's unique identifier in a *.id file. I was thinking that on the NTFS filesystem, this could be stored in a second stream for each file under revision control, thus keeping your working directory "clean", and roughly half the size.
;-) but I just thought I'd throw it out there.
They've probably already thought of this
Chip H.
However, I believe "archive mirrors" does what you are trying to achieve. I haven't used them yet myself, since I need the pivot branch to work with my coworkers.
No. archive-mirrors is a tool for star merges. If you have a remote archive foo, you can make a local mirror called foo-MIRROR. You can then easily check out of the local mirror, make changes, submit to the remote server, sync the local to the remote archive. This is not too economical on bandwidth, but I use it to have local "security copys" of my archive (my final thesis) on different machines - it works pretty good for that.
If someone has a good way to easily move the "master archive" around, tell me!
(Like this:) I have two machines (A and B).
The archive on machine A is up-to-date.
1) Make a local copy of the archive on machine B.
2) Work on the local copy on B.
3) Update the archive on machine A with the changes made on B.
Perforce ROCKS, but its per-seat price is like a good hard kick in the balls. If someone could re-implement it in an OSS project it would be COOL.
DJB wrote a revision control system!
Last time I checked arch had a couple of major weaknesses that I *did* consider showstoppers:
1. Requires that you use files named according to its conventions, not those of your software.
2. Falls over on filenames with spaces in.
Fix those, and I'd use arch. (Yes, I know they're working on #2.)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
The main problemw ith a GUI is that you can't script them (or not trivially anyway).
Okay, this is a pet peve of mine and (surprise) it does relate to arch, subversion, et al. The problems Tom Lord mentions are found everywhere in open source, and that is why X.org, arch and other 'duplicative works' or 'hateful forkings' exist.
It is very trivial to script a properly built GUI. Now the deifintion of a 'properly built GUI' goes beyond being able to be scripted, but does include this feature.
How? Why? From HCI and study of disability access we know that every action possible in a GUI should be performable with out a mouse. On Microsoft Certified Software this usually means everything has a contextually unique hotkey.
Windows 3.1 included a nifty tool called Recorder. Recorder is a lot like UNIX typescript, i.e. type 'script' and it records all the stuff in your command line session until ^D, except it only recorded your inputs to the computer. ALL GUI. No Terminal. Using the run box and keyboard (hot-key) only commands you could record a fairly portable script to automate your task. Given that the script (macro) was in textual format (IIRC) basic text editing skill was all you needed to turn a simple script into whatever you wanted (including being driven by command line scripts.)
The utter lack of standards compliance in Linux GUIs contrasts with the impresively standards-compliant command line applications (that are often definitive or reference implementations.) Let alone the lack of support for something like uniform contextual keyboard hot-keys.
A GUI for arch or CVS or subversion could be made with scripting in mind. And not just via embedding LUA or another 'lighweight' language. However, proper GUI scripting would take a project on the order of the Ximian Desktop to make it work even as well as a cheesy under-utilized program from 1980's Microsoft.
(Oh, and scripted GUI + decent version control GUI + automation tool = 100% developer envrionment matched automated test setup. Which can potentially be very cool if a bug is due to how a naughty newbie code monkey setup his little development cage. It's happened. And I've had to clean that monkey's cage one time too many.)
-----
Ugh. That's two pointless rants in one day. I need caffine.
"You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
I just want a tool that helps me get the job done.
I don't think you know how to get the job done if you're 1) arguing against proper good use of namespaces, and 2) you think aesthetics can be more important than that.
How, exactly, do you go about making a CLI easy to use when the average user calls the case the "hard drive"? Just wondering.
and sometimes (especially if you're a business) you'd really like to have the "obliterate" command.
:-)
Also, Subversion died on me unrecoverably after about a month of not very frequent use at home. And that's something I'd really hate to see here at work, where there are fifty devs checking in crap 24 hours a day.
I have a huge amount of respect for him. He taught me that compromise is way overvalued.
Personally I find GUI VC front-ends to be a painful barrier to coding, thought I realize some people may feel differently.
Proper IDE integration comes in handy sometimes, but OS integration usually just hurts.
sic transit gloria mundi
I'm still using CVS and there are two things that makes CVS very interesting for me .
*) Rsync Mirroring
*) Symlinks in CVS
rsync over ssh and lots of clunky symlinks is what I have in my CVS . I don't know how I'll ever port this into SVN or ARCH.
Quidquid latine dictum sit, altum videtur
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.
I've read a bit about CVS/Arch and their possibilities. It seems that CVS for example, is very widely used. What do you think one should use for a '/etc' versioning sytem? Since i'm still new to this i'd might as well learn the most flexible tool i guess.
Why there are CVS systems? CVS systems exist in order to coordinate source code sharing between multiple people. In other words, CVSs are information management mechanisms.
Why can't we see that CVS is just another version of the solution for the same problem? that problem is distributed information management. There are numerous places that this problem pops up: distributed filesystems, distributed databases, e-mails sharing between applications, source code sharing, etc.
It should be the role of the operating system to provide distributed information management. It would render a whole class of applications unneccessary and it would make programming much easier.
It is a great chance for open source software to provide this solution at open source level and gain a great technological, economical and social lead over propriatery software.
The most prominent error in current Arch is the name of the command line application: tla.
tla = Tom Lord's Arch I suppose.
What is next? gcc renamed to rmsc (RMS compiler)?
For vanilla C code clearmake is great. But you have to do a major amount of hacking to get the Sun C++ compiler's template repository to work with ClearCase. Ditto for Java and its class files. The Clearmake model of one source file per object file breaks down when the compiled source files create more than one resultant file under certain conditions.
Sure, basic scripting of a GUI is easy. But what do you do when you the next action depends on the result of the previous action? On a command line, if-then and looping is easy. In your average GUI scripting tool, however...
an exploited piece of shit who gave birth to an exploited piece of shit.
This is one of two big things I miss from VMS/TOPS-10. File versioning was very valuable. The ";n" filename versioning worked surprisingly well considering it was such a simple implementation. (For the uninitiated, VMS automatically maintained the most recent version without the ";n".) I wish *nix had this.
TOPS-10 (not sure about VMS) also had project as well as programmer permissions - kinda like groups but more powerful and useful. Once logged in as a user, you could change projects. Your login would look like, e.g., "user[alex:kerneldev]. Thus files and directories were owned by a project as well as a user, and the system maintained accounting data for both. It was easy to allocate and track work time and resource utilization to projects.
The third big thing I'd really like to have is the transcripting facility in the Perq workstation's text editor. (Perq was an ancient workstation - I have three, will consider selling them as I need the $$.) The editor maintained a transcript of all changes made to the file and stored them on disk. In the event of a crash this transcript could be replayed while you watched. Besides being interesting to watch your own work in fast-time, it allowed recovery from the beginning up through the last block saved. VIM has a short transcript/replay, but it's cumbersome to use for anything more than a few keystrokes. It also has a basic recovery capability but doesn't work as well as this. I dunno about Emacs these days. I once restored a marathon 36-hour programming session (deadlines breed insanity!) using replay. The ideal would be a kind of 'tape' feature in the editor, which one could fast-forward and rewind by using a GUI, and grab that part where you wrote a nifty bit of code (or text), but then backtracked and went a different direction, and now you need that nifty bit.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
In my view, the biggest barrier to adoption of new source code control systems is the confidence level. CVS suffers from lots of problems, but they are well understood due to the age of the system. Similarly I only trust Clearcase for my commerical development as it has been around so long (although BK is progressing well with gathering a bigger user base)
For any new system to be a contender it needs to have either a large existing user base (chicken and egg problem) or a very comprehensive test suite with code and problem domain coverage figures. If I am going to trust my (assumed valuable) source code to an SCM system, then I need to know that it behaves correctly. DARCS scores lots of points for being based on a semi-formal proof of correctness, but that only proves the algorithms not the implementation.
I've discussed this on Shlomi Fish's mailing list "Better SCM", but the real opportunity for all of the open source SCM projects is to collaborate on collating normal and pathalogical examples of SCM problems and building a common test suite.
Asmo
tla/arch is Tom Lord's Arch?
Did we really need another three letter acronym for that?
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
It is very trivial to script a properly built GUI. [...]
How? Why? From HCI and study of disability access we know that every action possible in a GUI should be performable with out a mouse. On Microsoft Certified Software this usually means everything has a contextually unique hotkey.
Great, so now we've got a script that's not portable to people using other locales.
http://www.drjava.de/superversion/ Uses change sets, and it seems rather stable and friendly.
There's an arch tutorial out there called "arch Meets hello-world." I've got it up in my browser right now, and due to the size of the tab, it shows up as "arch Meets hell."
What do people think of Arch or Subversion in comparison to commercial systems?
In particular, I've been working on a Perforce hosted project. VERY large (about 30 million lines in the depot) with hundreds of developers.
Of the version control systems I've used it's the best by far, but I've never used a system I really liked. So, I'm wondering what other people have found to work well.
Think big project, many files (many binary resoures as well), to many long lived brances with major cross merging, and hundreds of full time developers.
plus-good, double-plus-good
IIRC
I am NaN
How, exactly, do you go about making a CLI easy to use when the average user calls the case the "hard drive"? Just wondering.
You don't. It's impossible. It's also impossible to make a functional GUI easy to use for said users. You make it easy to use for competant human beings, not average users.
These free version control developers sound like they have never used clearcase. I think if they had spent time in a large commercial house using clearcase, they would pack up there keyboard like when a middle-ages alchemist walks into the kennedy space center.
really these projects are eons behind clearcase. that clearcase is an expensive proprietary package is a separate issue. gimp vs photoshop is another debate, the difference is that gimp does much of what photoshop does. CVS/BK/arch/whatever have like 0.0001% of clearcase's functionality.
so this is actually quite a joke
on that note: anyone want to start a free clearcase replacement - lets call it "seethroughissue"