linux-mips
[Top] [All Lists]

Re: Git

To: linux-mips@linux-mips.org
Subject: Re: Git
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 14 Sep 2005 13:37:50 +0100
In-reply-to: <20050914095858.GD23161@lug-owl.de>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20050913124544.GC3224@linux-mips.org> <20050913133126.GO23161@lug-owl.de> <20050913152038.GE3224@linux-mips.org> <20050914095858.GD23161@lug-owl.de>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.2.1i
On Wed, Sep 14, 2005 at 11:58:58AM +0200, Jan-Benedict Glaw wrote:

> To:   linux-mips@linux-mips.org

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

<Prev in Thread] Current Thread [Next in Thread>