Re: If no such changelist, show we error?

> > > > cl has committables: commit them
> > > > cl has files but no committables: silently exit 0
> > > > cl has no files: silently exit 0
> > > > cl does not exist: error out
> > >
> > > In the current implementation, this distinction does not exist. There
> > > is no mapping from changelists to entries; rather, each wc entry may
> > > have a changelist name.
> >
> > Ah, I guess that's why it behaves this way now. It's not really
> > a list, but a label or tag that files may nor may not have. Hm.
>
> Indeed. In fact, the nature of the changelist leads to a couple of
> other behaviors which I find unintuitive as a user (though sensible
> once you understand the current implementation):

Very unintuitive but also completely understandable with a brief explanation.

> As we discussed on IRC, svn commands never "recurse up" from the
> highest ancestor of the files listed on the command line (or the
> working directory if no files are listed). This means that the files
> referred to by any --changelist command (other than commit, which is
> special) depends on the current wc. That is, "svn diff --changelist
> foo" may not show all of the changes conceptually on changelist "foo";
> instead, it shows those changes that are at or below the current
> directory.

Equally unintuitive but understandable given the WC model.

> Another violation of a user's expectation that a changelist is in some
> way atomic is the changelist-unsetting behavior of commit. I like the
> behavior that "svn ci --changelist bla" removes the items from the
> "bla" changelist afterwards, and that you can use --keep-changelist to
> keep it around. On the other hand, I think it's rather unexpected
> that "svn ci foo.c" removes foo.c from any changelist it's on even
> though changelists aren't being mentioned at all.
>
> Does anyone else find this properties of the current changelist
> design/implementation surprising?

If changelists are intended to hold paths rather than scheduled
changes then I'd have expected items to stay on changelists and for
changelists to be a feature of the working copy as a whole - allowing
a path to be listed on multiple changelists and for changelists to be
persistent after commits (unless a user specified option at
commit-time cleared the paths from the specified list) would allow for
a more natural usage if changelists really are lists of paths rather
than scheduled changes.

I think a major review of many of these decisions (and unfortunately a
shift in the meaning of some concepts for the user) will be necessary
when/if the fundamental centralisation of working copy book-keeping is
ever done.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org