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

Re: If no such changelist, show we error?

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-08-19 01:32:49 CEST

On 8/18/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> "David Glasser" <glasser@davidglasser.net> writes:
>
> > On 8/18/07, Eric Gillespie <epg@pretzelnet.org> wrote:
> > > No, if the changelist doesn't exist, I agree we should error. I
> > > was disagreeing that we should error if the cl does exist, but is
> > > just empty.
> > >
> > > 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):

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.

(And I do mean the current directory: if you type "svn diff
--changelist foo /path/to/some/wc", the changelist will be gathered
from the *current working directory*, not from /path/to/some/wc.)

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?

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 19 01:30:29 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.