Re: GNOME DVCS Survey Results

On Sun, Jan 4, 2009 at 11:05 PM, David Zeuthen <david fubar dk> wrote:
On Sun, 2009-01-04 at 22:47 +0100, Frederic Peters wrote:
> Probably just like bzr already went through several repository formats
> and allowed easy upgrades (just like Subversion repository format
> changed and it didn't cause any problem for users).  I don't think
> there is a problem here.

I don't find this answer compelling. At all. It also doesn't answer the
question. It's not unlikely that a future git repo format is
fundamentally incompatible with current or future bzr repo formats.

> And also, data would be available in native git format on lots of
> computers, and could always be pushed to a vanilla git server.

Someone really got to explain exactly why support for multiple
repository formats is desirable.

To put it straight: the git repository format is not as awesome as people want to believe.

First, it only makes it much harder for users to grasp; we're going to
end up with some projects have l.g.o pages / README files / mailing list
messages saying "use bzr to check out this branch" and others saying the
same for git. That's *not* desirable; it makes it so much harder for new

That's not what John's proposal is about ! John wants to use the bzr format as a repository format, and add a git-serve plugin to bzr to be able to "talk" to the git clients. In other words, you will be able to access the same data using either bzr, git or hg.

Second, it also makes it harder to set up things like jhbuild; either
you end up pulling from both git and bzr (from the same underlying repo)
or you end up mentally having to translate branch names etc. from one
system to another. This is error prone.

Third, I could go on with examples, just consider the set of webtools
(cgit, annotation, source code searching etc.) we end up with on; some would be built against bzr, others against git. You
get inconsistent branch names, you end up overloading contributors with
different concepts and so forth.

Finally: We're talking about people's data here. The first rule of
holding peoples data is that you don't screw around with it "just
because". Data integrity matters. Keeping things simple and staying with
a *single* kind of hammer (instead of a weird homegrown mutant hammer)
helps here. Otherwise we end up with data loss. Frankly, I'm concerned
that some people are even considering using such homegrown kludges for
holding our GNOME source code.

Comparing the size of the Bazaar unit tests with those of Git, I would certainly choose Bazaar for storing my data.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]