[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: David James <djames_at_collab.net>
Date: 2006-03-02 04:31:28 CET

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.



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
Received on Thu Mar 2 04:32:05 2006

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