[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Giovanni Bajo <rasky_at_develer.com>
Date: 2006-03-02 12:04:07 CET

David James <djames@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
>> 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
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 2 12:05:50 2006

This is an archived mail posted to the Subversion Dev mailing list.