Monotone analysis

[Luke Schierer]

On Wed, Jul 09, 2008 at 04:04:03PM +0300, Felipe Contreras wrote:
> 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.
> >
> 
> I asked you before; did you run git-gc?

I am sorry, I did not see that question.  I did not.

> 
> 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.

I am unsure when it was introduced, but I've also an old source for git
laying around, which indicates I was using 0.99.9h or 0.99.9i, not sure
which.  Neither have a git-gc available.

> 
> 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.

shallow clones are indeed interesting.

> 
> 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?

as git-gc didn't exist, I'm going to bet that _at that time_, we would
have been stuck with the unpacked repository.  That means that the
objections against git then are just as strong as I've presented them.

At the time, as I tried to express, the field was much wider, and the
available data on which of the many dscm available would make the best
long term choice much sparser.  

> 
> 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.

*shakes head* I'd argue that even the worst of the DSCM is better than
subversion or cvs.

> 
> > 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

Either way, I am impressed with the results of git-gc, now that it is
available.  It takes my nearly 700mb repository and reduces it to 44mb.
Very impressive.

Luke