--changelist interpretation. Again. (And until we get this right.)

I've been thinking (and telling others) that the --changelist option on our
command-line is but a filter. That Subversion does the following for any
operation that supports --changelist:

    1. builds a list of operation targets (from the command-line, and
        from --targets)
    2. operates on those targets, but only doing meaningful things for
        those targets (or those children of them in the recursive case)
        which match the specified --changelist name.

So, I thought I'd found a bug today when I did this:

   $ svn cl foo T* README
   Path 'TODO-1.5-branch' is now a member of changelist 'foo'.
   Path 'TRANSLATING' is now a member of changelist 'foo'.
   Path 'README' is now a member of changelist 'foo'.
   $ svn cl bar T* --changelist foo
   svn: warning: Removing 'TODO-1.5-branch' from changelist 'foo'.
   Path 'TODO-1.5-branch' is now a member of changelist 'bar'.
   svn: warning: Removing 'TRANSLATING' from changelist 'foo'.
   Path 'TRANSLATING' is now a member of changelist 'bar'.
   svn: warning: Removing 'README' from changelist 'foo'.
   Path 'README' is now a member of changelist 'bar'.
   $

What?! Why did README get picked up? It doesn't match T*!

I poked sussman on IRC, and he corrected my understanding of --changelist.
See, apparently --changelist only behaves the way I expected for 'svn
commit'. But for other commands, --changelist is an additive thing, not a
filter. The presence of '--changelist foo' means, "Oh, and *also* do this
operation on things in '.' that are in changelist 'foo'."

I ... I didn't even know where to begin complaining about that.

This magic treatment of '.' is unprecedented in Subversion. I mean, yes, we
have '.' as the default target of most operations, but that default goes
immediately away if a single explicit target is provided. The inconsistency
between 'svn commit --changelist foo' and 'svn somethingelse --changelist
foo' is confusing, too. If 'svn ci /path/to/wc --changelist foo' will only
commit 'foo' items, why won't 'svn pset changelist foo /path/to/wc
--changeset foo' only set a property on 'foo' items?!

As it is, users who might be sitting in an unversioned directory get the
following confusing behavior:

   $ svn cl foo ~/projects/subversion/T*
   Path '/home/cmpilato/projects/subversion/TODO-1.5-branch' is now a member
of changelist 'foo'.
   Path '/home/cmpilato/projects/subversion/TRANSLATING' is now a member of
changelist 'foo'.
   $ svn cl bar ~/projects/subversion/T* --changelist foo
   subversion/libsvn_wc/lock.c:868: (apr_err=155007)
   svn: '.' is not a working copy
   $

'.'? Who said anything about '.'?

And, if --changelist is in fact supposed to be additive, why do we only
notice that most recent --changelist instance on the command-line?

   $ svn cl foo T*
   Path 'TODO-1.5-branch' is now a member of changelist 'foo'.
   Path 'TRANSLATING' is now a member of changelist 'foo'.
   $ svn cl bar README
   Path 'README' is now a member of changelist 'bar'.
   $ svn st -v --changelist foo --changelist bar

   --- Changelist 'bar':
               28588 28161 stylesen README
   $

On IRC, Ben and I are trying to recall the history of the feature. He says:

   <sussman> honestly, I think I agree with you
   <sussman> I think what happened was that I did the filter for commit,
             because it was the only "sensible" thing. and it was the
             first thing I did.
   <sussman> and after that, I got lazy (stupid?) and just implemented
             additive targets for other commands, probably thinking about
             the --target stuff from julian.
   <sussman> but I think you're right -- the Right Thing is make it a
             filter everywhere
   <sussman> I mean, I clearly noticed the dependence on CWD, and nobody
             seemed to object when I pointed it out; david james even
             said it was fine with him. :-/
   <sussman> but it's a bad decision in retrospect.

Of course, the bum thing is that doing the Right Thing is quite a bit more
complex, involving passing lists of changelist to all the major
libsvn_client functions.

So, what to do? I don't want to release a 1.5 with --changelist the way it
is. I mean, maybe if it works as expected on 'svn commit', we can leave it
there. But for the other APIs, I would vote to fix it super-quickly or
remove it until post-1.5.

Thoughts?

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand