Monotone analysis

[Felipe Contreras]

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