[Svnmerge] Re: svn commit: r18649 - trunk/contrib/client-side

[Giovanni Bajo]

David James <djames at collab.net> 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 don't think it's worth, as it would be semantically unclear for the users
("bidirectional block, say what?"). A reflected revision won't be shown in
"avail", so it's hard to see an user blocking it. And even if it's blocked,
it doesn't hurt.

>> 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'll try to find a little time to revert your patch and commit this.
-- 
Giovanni Bajo