Re: GNOME DVCS Survey Results

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.

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

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.


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