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

Sorry about the inconvenience caused! I didn't know of a better way to move the packages than to move the dirs in the repository. If you could outline here how it's most appropriately done we'll do a better job next time.

Thanks!

One possible way of making that change that would both preserve the revison history of those packages and prevent the current brokenness would be to duplicate rather than move the repository directories in question, and then in a correctly checked out working copy "cvs rm" them from HEAD. This would leave entries for (for example) acs-workflow in the main packages directory so that the tags for 4.x releases could still refer to the actual source trees that were released (strictly speaking you'd get a copy of the released sources plus duplicate copies of the packages in question in the obsolete directory, but I'd rather have a second copy sitting around that I won't use, than have no copy of a package I depend on).

I've brought up this issue with the other OCT members. I am preparing documents, migration path, and a TIP for OpenACS to switch to using the GNU Arch SCM to replace CVS.

It is simple, has very advanced features for distributed repositories and merging, makes is much easier to maintain an OpenACS repository with your changes while still being able to synch with the main repository, etc.

Talli and Ben Bytheway are the ones who introduced me to it. I've been using it and it is great.

-Roberto

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!

arch looks pretty impressive. I've made it part way thorough the tutorial and it seems to work as advertised. The commands are more understandable, as is the branch naming being related to the directory structure of repository.

One deficiency, which is probably just a configuration detail, is setting up a networked repository. The only safe method is sftp. Possibly ftp can be redirected over ssh?

One very nice feature is the use of a log file, instead of a log message. The tutorial suggests creating the log file before you start work and then add to the file as you make changes. Once you commit the log file is removed.

I googled for this deficiency and it looks like the sftp developers are addressing it, but it may not appear in the ssh release soon.

Regarding (2): How many of our _developers_ committing code to the OpenACS tree rely exclusively on Windows, without access to a *nix box of some kind? My experience with the community says that it's a very very limited number. Do we even have anyone running OpenACS on Windows?

Sure it would be great if it worked everywhere, but we have to consider if it's worth it to continue to inflict pain on the entire development community because of a very restricted set of developers that we're not even sure exists.

Of course we'd continue to provide things like nightly tar balls, bug-tracker where people can submit patches, etc. Using arch would definitely _not_ isolate users who rely exclusively on Windows.

Re: 3) Very much agreed, and I'm working on it. As far as "best practices" for CVS, what I usually see is a hodge-podge of hacks to work around its defficiencies. But if you're working on a system that doesn't have those defficiencies, many of the "best practices" are not necessary anymore.

-Roberto

I was the first advocate of moving to GNU Arch, and I even host gnuarch.org (along with Mat Kovach). But I still think Arch is 6 months to a year away from being ready for the OpenACS community to embrace it.

CVS may suck, but it's a least common denominator that most people understand and can use. If individual developers are willing to use Arch and synch that with a canonical CVS repo, that would be the fastest way to get moving with this stuff.

talli

I do want to thank Russell for bringing up this important issue.