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

Re: overlapping change lists?

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-10-08 20:19:15 CEST

On 10/8/07, David Glasser <glasser@davidglasser.net> wrote:

> $ svn ci --changelist foo
>
> if the user expects that to clear 'foo' post-commit. However, because
> of the way changelists are implemented for the commit command, only
> "committable" elements (and not unmodified ones) ever get seen by the
> commit and so unmodified items get left on the changelist. If they
> really are orthogonal it shouldn't make a difference!

I guess the original idea was that commit only de-changelistifies
things it actually commits. I can see why we'd want to change this
behavior, though... it's part of the idea of wanting to treat
changelists as a 'whole object'. Should we change the behavior?

(Keep in mind that we already violate 'whole object' guarantees, in
that if you run 'svn st' deep within a working copy, you may only see
part of a changelist, not the whole thing. That might change once we
centralize our wc metadata someday.)

>
> Also, with respect to the main issue here: I would support just not
> allowing directories to be on changelists, at least for 1.5. It does
> seem that having directories on changelists leads to a lot of
> interface complexity; if we're trying to start stabilizing this week,
> why not just limit the scope of the new feature? If we find that
> users are dying for a way to put directories on changelists then we
> can add that in 1.6; by that point we'll have a better idea of whether
> or not it is more useful to treat it as depth-0 or depth-infinity.
>

I agree that our choices are to either

(1) forbid directories being members of changelists, with the impact
that dirprop-changes can't be part of changelists

or

(2) fix 'commit' and 'diff' to treat directories as depth-0

I suppose you and Malcolm are pushing for option 1, since it's simpler. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 8 20:19:27 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.