Monotone analysis

[Felipe Contreras]

2008/7/9 Richard Laager <rlaager at wiktel.com>:
> On Wed, 2008-07-09 at 07:38 -0400, Luke Schierer wrote:
>> Would you really consider working on pidgin to contribute that one
>> patch if you had to download [an ISO's worth of data] just to get
>> going with our DVCS?
>
> BZR, from what I understand, can do CVS/SVN-style shallow checkouts.
> They also point out a potential problem with git's shallow checkouts,
> but I can't speak to that. [1]

>From the documentation:
A shallow repository has a number of limitations (you cannot clone or
fetch from it, nor push from nor into it), but is adequate if you are
only interested in the recent history of a large project with a long
history, and would want to send in fixes as patches.

I don't see the problem with that. You would probably want a shallow
repository only for patches, or keeping track of the code.

> With regard to git, the issues in [2] would concern me. Obviously,
> that's a biased page, so I'd be interested to read something from the
> git folks about that, but I haven't done any searching to find it yet.

It's incredibly biased, I've tried to read it but I don't think it's
useful, I just skimmed through it. They are just gathering all
possible issues, and even when they found out the issues aren't
actually there they just add a note instead of removing the point.

About that "robust renaming", they say it breaks under certain
conditions, but there's no reference, I don't think it's true. Git
automatically finds out if the files are similar enough 50% at least,
I think. So you don't need to care about renames ever again, if the
file is more than 50% different than the original you can see it as a
new file anyway.

What happens if you apply a patch that renames a file? There's no
problem with git, with bzr you need to be careful I guess.

> I found [3] to be an interesting read (it was linked from [1]/[2]).
> Also, it seems BZR has a feature that I wanted out of Monotone for some
> time. [4]

Indeed I agree with most of the points, but these are cosmetics. I
have some ideas about how to improve git's index, which is what most
people have trouble understanding, hopefully I'll find to implement
them.

Again, the UI can and will improve, but the underlying design won't
change much, that's why I think it's more important.

Best regards.

-- 
Felipe Contreras