Monotone analysis

[Felipe Contreras]

On Wed, Jul 9, 2008 at 2:38 PM, Luke Schierer <lschiere at pidgin.im> wrote:
> On Tue, Jul 08, 2008 at 01:45:19PM -0700, Ka-Hing Cheung wrote:
>> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote:
>> > = Git recommendation =
>>
>> Sure monotone is slower, but is it fast enough? Sure the monotone db is
>> bigger, but is it really that much of a problem? Maybe there are less
>> tools for monotone, but the extra tools for other DVCSs are worthless if
>> we don't plan to use them anyway.
>>
>> While I don't dislike git or anything else, and think that starting with
>> monotone now is a little silly, I think the important thing here is
>> whether the cost of switching is worth it. Many of us spent quite a
>> while to learn monotone already, and it's hard to spend time to learn
>> something else unless it's clear that there's significant return. Also,
>> if we switch to X now, should we switch to Y when that becomes _better_?
>>
>> Pidgin isn't in the business of developing DVCSs. If monotone becomes
>> not good enough, or if there's a clear winner in the DVCS space, then
>> ya, maybe it's silly to keep using monotone then.
>>
>> -khc
>
> Git must have really improved since we made the switch to monotone.  I
> did some digging around, and since I am quite nearly an invenerate
> pack-rat, I found a working copy of a git repo I created back when we
> were evaluating which dvcs to use.  The git repo from then is 649M, my
> much much newer monotone database is only 244M.
>
> I recall that the size of a git database was such a problem that the
> kernel developers weren't even trying to use a database with an entire
> history in it, they dumped all their historical stuff in one repository
> and had another with just the 2.6 stuff in it.
>
> Looking at it now, it appears that their basic work flow is that anytime
> someone does significant enough work that someone else might want to
> help them with it, before it is merged into the one head, they create a
> new download target on git.kernel.org.  Though I could be wrong here,
> I've spent very little time thinking about git since we made the
> decision, and I'm a little foggy on how it works now.
>
> Still, there are some important things to remember here.  We spent
> considerable time and effort evaluating our options when we made this
> switch.  I am a little tired of the idea that we made it relatively
> arbitrarily.
>
> At the time there were a number of apparently equally viable DVCS.  I
> looked at _all_ of them, including git, bzr.  hg, at the time, was not
> even used by redhat, and did not appear to be really viable, so I admit
> I did not look at it.  Of the ones out there, while a fair few had
> started implementing subversion -> $dvcs support, only two had _working_
> support, git and monotone.  At least, several had support that
> _appeared_ like it it _might_ work for much smaller repositories, but
> only two could handle _ours_.  We wanted to have the full history
> available to us.
>
> Of them, git, at the time, as you claim this is solved, required almost
> a full CDs worth of space just for the repository.  Unlike monotone,
> this repository has to be stored _per working copy_.  That means if I am
> working on head in pidgin.my/ and gobjectification in pidgin.gobject/
> and 2.4.x in pidgin.2.4/ then I incur this cost 3 times, whereas with
> montone I have one database, and so incur the cost once.  Monotone
> _could_ be larger than a git repo and still be a clear winner (space
> wise) on this alone.  In fact, this was one of the deciding factors in
> picking monotone over git.  Several developers expressed a very strong
> dis-interest in re-learning their work flows to be able to effecitently
> work on multiple projects in one working copy.
>
> Another consideration is that downloading an ISO's worth of data is, or
> at least was, non-trivial for a substantial number of people, again this
> was a concerned expressed by some developers at the time.  Would you
> really consider working on pidgin to contribute that one patch if you
> had to download that much just to get going with our DVCS?
>
> While I have always been attracted to git _because_ it is used by the
> kernel developers, and I figure that this fact will ensure that it
> continues to be improved on, and ensures that it will continue to have a
> substantial body of users who are familiar with it, I really don't think
> our choice of monotone was unreasonable given where we were at the time.

I asked you before; did you run git-gc?

At that time git didn't pack objects automatically, you had to do it
yourself, if you didn't the objects where unpacked, loose, taking a
lot of space.

I've been trying to find at which point packing was introduced, and
I've gone as far as 1.0.0 (2005-12-21) and it seems to have been
supported since then.

Moreover, contributors don't need to download the whole repo, you can
have bare clones. You decide the number of commits of depth you need,
strictly you only need one commit, which would be the equivalent of a
cvs checkout.

I'm not saying you didn't spend enough time considering alternatives,
maybe you did. But spending time on a task doesn't mean the task is
well executed. I find hard to believe that you did a proper job at
looking for alternatives because of the result: switch to mtn. I bet
other projects considered a SCM switch at the same time, and few, if
any, decided to switch to mtn, does that means they made the wrong
choice?

It's OK to look back and say: I tried hard, but I still made the wrong choice.

At best, I would have expected the result to have been; the best is
mtn, but it's too early to choose a DSCM.

> I wouldn't mind switching now if 1)there were a clear benefit to doing
> so and 2)a degree of certainty that we won't be switching again in
> another couple years.  That being said, I don't think we want to throw
> away our work on trac _now_, so we'd want to make sure all the pieces
> were in place for trac integration _before_ the switch.

For an example of trac using git:
http://www.pulseaudio.org/browser

-- 
Felipe Contreras