[Svnmerge] Ignore initialized revisions (was Re: Reflected blocks)
Giovanni Bajo
rasky at develer.com
Mon Jul 30 07:35:24 PDT 2007
On 7/30/2007 4:01 PM, Michael Willmott wrote:
>>> To sum it up: if my reasoning is right, I'm OK to make this patch go
>>> in only if there's a followup patch to deprecate --bidirectional and
>>> make it always on by default.
>>
>> I haven't really been following this thread, but just wanted to point
>> out that a few months ago on this list I had made a proposal to have
>> svnmerge.py determine whether to use the bidirectional logic or not
>> internally based on whether the source branch had merge information
>> for the target branch. That would allow deprecating the
>> --bidirectional flag, but maintain the speed advantages for
>> uni-directional merging (except for one extra pg call). I think that
>> proposal got a +1 from Daniel and Giovanni. Would that help here?
>
> Whilst that is a good idea, it does not help in this case since the
> patch introduces a performance hit in non-bidirectional operations.
Yes, I agree.
> I'm -0 on the patch in its *current* form. I think that the number of
> use-cases it addresses is probably minimal, and that without sufficient
> end-user demand to offset the performance hit, should probably be left out.
I understand this. I used to be pretty vocal against performance hits
which affected simple users for complex scenarios they won't probably
ever met.
Maybe we could gate this feature on --bidirectional as well. It's not
*exactly* the same thing, but I think that most advanced users have
already learnt that --bidirectional makes avail be more precise, so it
could be a good compromise.
Meanwhile, we can explore way to speed up --bidirectional...
> One alternative would be to make the new behaviour optional. Other than
> Rich, has anyone expressed issues with the lack of initialized revision
> detection in svnmerge?
I do. It's pretty annoying when working on complex repositories.
--
Giovanni Bajo
More information about the Svnmerge
mailing list