[Svnmerge] [PATCH] Bidirectional patch take 2

[Blair Zajac]

Giovanni Bajo wrote:
> Blair Zajac <blair at orcaware.com> wrote:
> 
> 
>>That's one command out of many that the svnmerge.py runs.
> 
> 
>>[...]
> 
> 
>>I'm also more concerned about having svnmerge.py operate correctly than
>>speed. I don't see it as gratuitous.  I would rather see an optimization
>>flag to turn off bidirectional support than the other way around.
> 
> 
> It's the one command that weights most in the "svnmerge avail" time. I don't
> consider making "svnmerge avail" twice as slow in a repository without
> reflected revisions a good tradeoff for having an improved correctness. It's
> improved over what it does now *iff* you use reflected revisions. Not
> everybody does that, it's really possible to have and handle branches
> without bidirectional merges, it's a common use case, and we're failing to
> provide a zero-impact --bidirectional flag.
> 
> I propose to throw it in, keep it as non-default, and I'll have my GCC users
> run more tests. Let's see what it turns out. Meanwhile, it would be great if
> we could push SVN towards providing more fine-tuned information. For
> instance, if "svn log" grew a -N (--non-recursive) option, we could use "svn
> log -N --verbose -quiet" to acquire the very small list of revisions which
> modify a directory property, which might improve --bidirectional a lot.

Yes, that would be a nice feature to have.

Blair