Raman Gupta wrote: > Giovanni Bajo 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. 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. 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? -- Michael Willmott _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
