Source code control

[ron minnich]

one thing I don't much like are packages that require users to get a bunch 
of software and load it before they can get the package. I like to 
minimize barriers to entry, and we probably have all seen situations where 
to get package Y, you need to get package X, which doesn't work on your 
system Z due to conflicts with language/compiler A, B, and C. 

darcs requires people to get a Haskell and build it. Not so sure I like 
this.

arch is a single C program but if we are really proposing changes I'd 
rather not end up with maintaining an RCS as part of the project, so I 
think the changes should go back into arch if they're really needed. 

In the end, what does arch do better than bitkeeper? I'd like to 
understand that. bk is used for the Linux kernel itself, as well as the 
infiniband source tree, which indicates to me that it is fairly robust. bk 
has the same problem as darcs and arch, however: users will need to get 
these and get them working before they can get etherboot/linuxbios. The 
infiniband project fixed this by exporting to sourceforge. But sourceforge 
was failing again for me today, so depending on that seems a mistake. 

The 'arch' web pages have a few 'we need help' items, which leaves me
somewhat concerned.

Is the motivation here perceived problems with CVS (not hard to imagine) 
or with sourceforge (also not hard to imagine).

ron