Forum OpenACS Improvement Proposals (TIPs): Re: TIP #25 (Proposed): No direct manipulation of the CVS repository

If it works as advertised, Arch should be significantly better for OpenACS use than SubVersion, due to Arch's direct support for distributed development (rather like BitKeeper's).

This February 2003 Linux Kernel list thread on version control had some interesting info. From that, it seems likely that Arch is still, at least currently, noticeably inferior to BitKeeper.

E.g., Olivier Galibert said, "Hell, arch is still at the update-before-commit level. I'd have hoped PRCS would have cured that particular sickness in SCM design ages ago." which sounds interesting, although I don't know what that means exactly. (But Tom Lord thinks it mostly meaningless drivel, and explains why.) And Linus Torvalds mentioned, "Give it up. BitKeeper is simply superior to CVS/SVN, and will stay that way indefinitely since most people don't seem to even understand _why_ it is superior."

It is not clear to me whether Arch's (assumed) inferiority to BitKeeper is fundamental, or Simply a Matter of Programming. Lacking any additional information, I would tentatively conlude the latter - Arch can catch up (eventually even surpass?) BitKeeper - but that doing so is probably hard.

Even so, that doesn't matter to OpenACS, as we've been getting along ok with CVS, which is much, much more inferior to BitKeeper than Arch could be! So if Arch is judged to be, useful, currently a substantial improvement over CVS, well-designed, likely to undergo regular further improvement and maintainence, and a better choice for OpenACS than other competing Open Source revision control tools, then OpenACS should use it.

Note that above I said competing Open Source tools. What about closed source tools, like BitKeeper? The Linux kernel project uses BitKeeper. The Linux kernel is an extreme case of needing the best distributed version control system you can get, and needing it right away. Linus obviously decided that this need was so compelling and immediate that it overroad any concerns over BitKeeper's non-open-source license. OpenACS is not in that situation; we have no such extreme and overriding needs. Therefore it should be easy and best to simply side-step all the huge acrimonious licensing flamewars that the kernel folks have gone through, by simply going with the best Open Source tool, and looking at closed-source tools primarily only in order to better understand and evaluate the open source ones.

Perforce? It's closed source of course, and I've never heard any arguments on why it's better than BitKeeper. My guess is it isn't, at all. If we were going to go with a closed source tool (bad idea), I think it'd be hard to come up with any good reasons to use anything other than what the Linux kernel folks already went with - BitKeeper.

Tom Lord (original author of Arch) made some fairly insightful criticisms of SubVersion back in February 2003. Basically, he thinks the SubVersion project is fundamentlly a failure, and is interested in understanding why and how.

Roberto, I would be very interested in seeing your stuff on OpenACS switching to Gnu Arch!

I'll be honest and say that I don't fully understand the DAG-based ultra-cool feature of BitK33per (using the 3's to avoid trademark issues), but I get the feeling.

Here's what I'm interested in for OpenACS:

- Making it easier for developers to work on their own tree of OpenACS and a) still be able to synchronize with the main tree, b) allow the OCT to grab their changes.

- No more merging nightmares and branch confusion.

- Keeping track of files regardless of naming in different trees.

arch gives us all of those. From my research, it'll make our lives much easier, and will greatly benefit those using OpenACS and wanting to have their own separate tree (i.e. a customized installation) while still being able to sync with the main tree.

Now I'm sure BitK33per would give us all of those and perhaps more. Their (Tcl/Tk-based!) graphical tools for one, are very impressive. Linus can afford to mandate a proprietary product that he helped design. Perhaps we could do that as well, but I'd rather not dwelve into that possibility.

We could use BitK33per, but that would mean that no one working on OpenACS would be able to contribute to other SCMs.

And honestly, I think arch will solve our problems just fine.