On Fri, Feb 27, 2009 at 1:21 AM, Felipe Contreras <
[email protected]> wrote:

>
> As I said, my objective is to generate git clone for people to
> develop/follow/maintain instead of the mtn repo, in this case there no
> need to have every single bit of information since the mtn repo would
> still be available.


Does a bit of "extra" information hurt this use-case somehow?


> On the other hand, when a project moves away from mtn to git, then
> your method makes more sense.
>
> That's why I think it should be an option.


So something like --use-one-changelog that grabs one of the changelog certs
at random and spits that out? Sorry, I'm really having a hard time seeing
how this could actually be useful. Are you just trying to get this export to
exactly match what your script produces so that they can compare
identically? If so, would it be possible instead to change your script so
that it appends all changelogs into one complete message?


> >> Anyway, I've been able to reach a little further and now I've finally
> >> found a difference in the trees between your and my method. In
> >> Pidigin's repo there's a commit
> >> '3f1b3854a77850131531d1d6f19c44a0b9174107' that in my method some
> >> files have exec flag off, and with your method it has the exec flag
> >> on. Can you take a look?
> >
> > Good catch. The monotone checkout of this revision has execute bits on
> some
> > files that the git checkout does not. I'll have to do some digging to see
> > what's going wrong here.
>
> I'm not exactly sure what you mean with this, but there's a bug in
> 'mtn update' that sometimes doesn't pick the correct exec flag. That's
> why I'm doing a full 'mtn checkout'.
>

Here's what I see:

A git checkout of refs/mtn/revs/3f1b3854a77850131531d1d6f19c44a0b9174107
from the exported git repo does not have execute permissions on
./po/{id,ne,ps}.po or on a few files in ./doc/oscar/. If I update a monotone
workspace to this revision it does have execute permissions on these files
and disagrees with the git workspace exactly on these permission bits.

A monotone checkout of the same revision does NOT have execute permissions
on these files and all permission bits are in agreement with the git
checkout. Note that this revision has no branch cert which apparently
prevents it from being checked out from monotone so I've added a bogus
branch cert  to my local database to make a checkout possible.

My impression at the moment is that the exported history does have correct
permissions because it agrees with a monotone checkout (which requires
addition of a branch cert) of the same revision. It seems that there are two
different problems with monotone here (1) checkout is not possible for
revisions that have no branch certs and (2) update doesn't always produce
correct execute permissions.

The problem is not your method, the problem is mine, which is
> painfully slow, but it's needed for a bit-exact comparison. It's
> tedious but hopefully the comparisons will soon be done.
>

It's great to have another method to compare the output against and make
sure both produce equivalent results so I do appreciate the effort. Have you
previously done lots of verification of the output of your script, to the
point where you trust it to a reasonable degree?

Cheers,
Derek
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel

Reply via email to