Re: Re-merge a change from own history - corrupts svn:mergeinfo

I wrote:
> Julian Foad wrote:
>> Problems:
>>
>> * svn:mergeinfo is touched despite the "--ignore-ancestry" option
>> which I though was supposed to suppress tracking.
>>
>> * svn:mergeinfo gets the wrong source path: "mergeinfo" instead of
>> "/trunk/subversion/tests/cmdline/merge_tests.py".
>>
>> * svn:mergeinfo gets corrupted (non-UTF8) text in it in the second scenario.
>>
>> The last two problems may just be follow-on symptoms of the first.
>
> I certainly agree there is a bug here, given that svn:mergeinfo is being
> corrupted. However, I'm not sure --ignore-ancestry does what you think
> it does. Its help just says:
>
> --ignore-ancestry : ignore ancestry when calculating merges
>
> Nothing there about not *recording* mergeinfo for this 'merge' command;
> rather, it's talking about how it selects which changes to merge.
>
> What you're thinking of would be a sort of opposite of the --record-only
> flag: a '--no-record' flag, which AFAIK we don't have (should we?).
>
> I do suspect the last two problems are the same problem under the hood.
> Initial debugging has revealed a separate problem, which I'd like to
> post about in a separate thread (or go discuss in IRC), so leaving off
> here for now.

Just FYI folks, Julian and I had this conversation in IRC:

<kfogel> julianf: responding to your mergeinfo corruption mail right
          now

<kfogel> first making sure I can reproduce

<kfogel> julianf: is the argument
          'subversion/tests/cmdline/merge_tests.py' part of your command
          line or not?

<kfogel> Can't quite tell, from how your mail is formatted.

* kfogel notes that the command now seg faults!

<julianf> kfogel: Yes there were two identical arguments, both
          'subversion/tests/cmdline/merge_tests.py', on the end of my
          command.

<kfogel> julianf: well, if you only use one of them, you can make svn
          seg fault!

<kfogel> I'm debugging that right now.

<julianf> :-)

<kfogel> julianf: suggest using \ for continuation lines in
          transcripts, it makes everything unambiguous.

<kfogel> Though in this case, the ambiguity led us to discover a seg
          fault.

<julianf> Sure, will try to remember to do so.

<kfogel> julianf: maybe we can figure out this seg fault right here,
          faster than me posting to dev@, filing issues, whatevre.

<kfogel> got a sec?

<julianf> Er.. certainly got a second, but trying to get my first
          expenses claim sorted out today hence mostly distracted from
          programming. But yes, let's go for it.

<kfogel> heh

<kfogel> okay, one sec

<julianf> I'll go to the command line now and try to reproduce your seg
          fault in GDB.

<julianf> (Yes it's "yours" now :-)

<kfogel> This is if you pass just *one* of the two file args from your
          email.

<kfogel> (I haven't tested with two yet.)

<kfogel> I'm in libsvn_client/merge.c:do_file_merge(). We enter the
          function

<kfogel> with 'honor_mergeinfo' set to FALSE, as expected. Now look
          at the big

<kfogel> block that starts with "if (honor_mergeinfo)\n {". Note that
          that

<kfogel> conditional block is the only place we set local var
          'mergeinfo_path'.

<kfogel> (There's also an 'else' clause that is two lines long. Since

<kfogel> honor_mergeinfo is false for us, we go into that 'else'
          block.)

<kfogel> Later, near the end of the function, we call
          update_wc_mergeinfo(),

<kfogel> passing it mergeinfo_path (which in my process has value 0x9
          :-),

<kfogel> which is obviously bogus -- it's just an uninitialized local
          var).

<kfogel> julianf: EOT :-)

<kfogel> julianf: aha, I can reproduce the seg fault even passing
          *two* args, just like your command line in fact.

<kfogel> Here, I'll write up a repro script for you.

<kfogel> julianf: http://pastebin.ca/959867

<kfogel> I'm assuming that's the same segfault as the one-arg version,
          although I haven't debugged the two-arg instance.

<julianf> It's very likely the exact same code path that results in no
          seg-fault but bogus mergeinfo on my system. Seg-fault probably
          depends on exactly what uninitialised value the variable gets.

<kfogel> julianf: makes sense

<julianf> Want me to have a go at fixing it? (Doesn't sound
          hard... famous last words.)

<kfogel> julianf: sure, go for it

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-27 20:16:58 CET