[Svnmerge] [PATCH] Bidirectional patch take 2

[Giovanni Bajo]

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.
-- 
Giovanni Bajo