Monotone analysis

[Luke Schierer]

On Thu, Jul 10, 2008 at 03:33:01AM +0300, Felipe Contreras wrote:
> On Thu, Jul 10, 2008 at 3:20 AM, Luke Schierer <lschiere at pidgin.im> wrote:
> > 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.
> 
> git-repack did that.
> 
> It's explained in tutorial.txt on 0.99.9h.
> 
> >> 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.
> 
> That's arguable, svn is not so bad.
> 
> >>
> >> > 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.
> 
> No, the repository back then was much smaller, I think the result
> would be around 15MB, probably less.
> 
> -- 
> Felipe Contreras

Um, no, Those numbers *ARE* from a repository from back then.  

luke