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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
