Re: svn commit: r18649 - trunk/contrib/client-side

On 2/28/06, Giovanni Bajo <rasky@develer.com> wrote:
> Well, the point is why "svnmerge block" uses code which depends on the
> bidirectional flag, yet the flag is invalid for it. In fact, "svnmerge block"
> *does* change its behaviour depending on the "bidi" flag: in fact, if
> opts["bidirectional"] is True, reflected revs are automatically filtered away
> from the block list. If opts["bidirectional"] is False, reflected revs might go
> into the block list. It doesn't really change much, but still. I guess we can
> live with the default for the flag, whichever it happens to be.

Do you think it would make sense to allow the "bidirectional" flag to
be used for svnmerge block? To me, either way is fine, as long as the
"block" and "unblock" commands still work.

> I guess the correct solution is to put defaults for all the common options
> within the state dictionary, no matter which ones are actually valid for the
> current command. The code that sets the defaults is currently in _fancy_getopt.
> Can you move it into parse() (near the beginning) and run it for all the global
> options (self.gopts) + all the common options (self.copts)? That should make
> it. Or get back to me and I'll try to fix it myself.

That sounds good -- would you like to do this?

I'm more interested in implementing better bidirectional merges when
you have multiple branches, you'll see a new email on this topic soon.

Cheers,

David

--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org