On Wed, Sep 14, 2005 at 11:58:58AM +0200, Jan-Benedict Glaw wrote: > To: linux-mips@xxxxxxxxxxxxxx If you actually expect finite time answer, don't delete the cc list ... > monotone > Is quite nice'n'easy to use for CVS users, you'll have quite a > fast start. The network sync protocol can be a bit lengthy at > a time, but it works. It's acceptable in speed, but not > exactly "fast". Written in C, code can easily be read and > hacked. Git has taken some ideas from Monotone. > darcs > Is easy to use, too, and quite some helpful. Network > operations are a bit slower than those of monotone, but the > real point is that it's merging algorithms are awfully slow. > Also, it's written in Haskell (and getting a working compiler > isn't exactly trivial), so the code is hard to read (for a C > person), mostly because Haskell's concept are so different > (it's a function programming language, after all.) In my tests at the beginning of the year darcs's performance was undescribably low. The speedup factor needed to make it useful for any large project probably cannot be described in a floating point number. > arch > Arch can do almost everything; it's network sync protocol is > quite fast (can use several transports and will make use of > caches). However, it's not exactly easy to use because of it's > thousands of commands and it's project name conventions are, > um, ugly. It has very good merging capabilities, but it's > heavy use of local caches forces you to have loads of free HDD > space. Git is a huge diskspace consumer also unless repositories are converted. For example, the Linux kernel repository from CVS did inflate itself to over 4GB and over 340,000 files. After packing I got that down to like 170MB. Not bad compared to the some 770MB of RCS files it's using currently and < 11s checkout from git can't be wrong either ;-) > SVN > Not distributed, easy to use. Though there's a different > frontend with distribution capabilities. Personally, SVN feels > like CVS with it's major conceptual problems fixed. And plenty of reports about database corruption that are not terribly old so I'd feel uneasy to keep the crown jewels there. > To get fixes/port updates/subsystem updates upstream to Linus, GIT is > the way[tm] to go, so we'd try to get familiar with it. The other accepted currency of the trade are still simple patches, see http://www.linux-mips.org/wiki/The_perfect_patch. Ralf
