Re: [Monotone-devel] git fast-export

[Felipe Contreras]

On Sat, Feb 28, 2009 at 7:41 AM, Derek Scherger <address@hidden> wrote:
>
> 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?

Yes, because you see two changelogs appended instead of one, possibly
with the comments too. It doesn't look like a native git repo.

>> 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?

I've changed my script to simulate yours when I think it's sensible,
otherwise I've modified your code to do what my script is doing. So
far this has been the only change that I'm still doing... once it find
a changelog, I break the loop.

>> >> 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.

That's really annoying! I've had to do many hacks in my script to make
the checkout possible... got parent by parent until there's one that
has a branch cert, checkout that, then update to the original commit.

> 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.

Agreed.

>> 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?

Yes I have. That's why I found issues in mtn in the first place. I've
been trying something foolproof, first I was doing 'mtn update' and
importing the exact workplace. Then I found issues and I tried with
'mtn checkout' and still I found issues (with no branches).

I've found that in the case of
3f1b3854a77850131531d1d6f19c44a0b9174107 my script is unreliable
because the result depends on which parent I'm basing my update. It
looks like my script cannot be reliable unless I avoid 'mtn update' or
it is fixed in mtn.

Could you make a patch that gets rid of the 'no branch' error?

-- 
Felipe Contreras