[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