On Fri, Feb 27, 2009 at 1:21 AM, Felipe Contreras
<address@hidden> 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