Monotone analysis

[Felipe Contreras]

On Thu, Jul 10, 2008 at 6:36 AM, Luke Schierer <lschiere at pidgin.im> wrote:
> 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.

Without packing.

-- 
Felipe Contreras