Source code control
rminnich at lanl.gov
Mon Jan 5 04:36:01 CET 2004
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
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
Is the motivation here perceived problems with CVS (not hard to imagine)
or with sourceforge (also not hard to imagine).
More information about the coreboot