You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jack Repenning <jr...@collab.net> on 2007/10/05 22:30:17 UTC
overlapping change lists?
There was some discussion, a while back, about overlapping change
sets. A perhaps over-brief summary seems to be:
> Several people wanted them well-managed, but Ben didn't think the
> problem was worth attention, so none was given it.
Some details of the implementation actually prevent overlaps (for
example, a given target can be in at most one changelist). But
overlaps are not completely prevented, and the system behavior when
they do arise is very surprising. Frankly, having just stumbled onto
these quirks, I'm feeling like they're an embarrassment to the entire
product, and shouldn't be allowed out the door. But I might be
overreacting. Examples:
$ svn changelist l1 src src/foo.c
$ svn changelist l2 src/bar.c
Question: is bar.c in list l1? Opinion differs:
$ echo >> src/bar.c
$ svn stat
--- Changelist 'l1':
src
src/foo.c
--- Changelist 'l2':
M src/bar.c
Guess not. But:
$ svn diff --changelist l1
Index: src/bar.c
===================================================================
--- src/bar.c (revision 2326)
+++ src/bar.c (working copy)
@@ -21,3 +21,4 @@
}
sleep(1);
}
+
Oh, guess it is. But:
$ svn ci -mx --changelist l1
svn: Unknown changelist 'l1'
"Unknown"? Even "stat" at least knows of this changelist, though it
shows no changes therein, what's this "unknown" business? OK, let's
try:
$ echo >> src/foo.c
$ svn ci -mx --changelist l1
Sending src/foo.c
Transmitting file data .
Committed revision 2329.
OK, so "ci" can make the intended sense of a changelist when there
are changes there, though not so much when they're not.
Then there's the behavior of auto-removal from a changelist. If you
commit a change, the item is removed from any change list where it
might reside; good so far. But if you commit the changelist, and it
contains some unmodified objects, they are not removed from the
change list. I can think of some workflows where that makes sense,
like "I need to make a related change to all these files, but I'll
commit them in chunks, say because I like to commit once a day." But
I could also tell that tale as "I need to make this change to all the
files in this directory, so I put the directory into the change list,
but hey, it never gets autoremoved because I'm not actually changing
the directory." The feature implements a certain workflow, but not
others, yet there seems no guidance on what to expect.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: overlapping change lists?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 10/8/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Ben Collins-Sussman" <su...@red-bean.com> writes:
> > 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. :-)
>
> I think (1) for now is better too, since then later we could add
> '--depth' as an option to the 'changelist' subcommand and Get This Right.
Oh wow, you're so right. OK, yeah, let's do this with --depth in svn 1.6. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: overlapping change lists?
Posted by Karl Fogel <kf...@red-bean.com>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
> 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. :-)
I think (1) for now is better too, since then later we could add
'--depth' as an option to the 'changelist' subcommand and Get This Right.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: overlapping change lists?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 10/8/07, David Glasser <gl...@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
Re: overlapping change lists?
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Oct 08, 2007 at 09:31:04AM -0700, David Glasser wrote:
> 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?
+1.
Regards,
Malcolm
Re: overlapping change lists?
Posted by David Glasser <gl...@davidglasser.net>.
On 10/8/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > $ svn ci -mx --changelist l1
> > svn: Unknown changelist 'l1'
> >
> > "Unknown"? Even "stat" at least knows of this changelist, though it
> > shows no changes therein, what's this "unknown" business? OK, let's
> > try:
> >
> > $ echo >> src/foo.c
> > $ svn ci -mx --changelist l1
> > Sending src/foo.c
> > Transmitting file data .
> > Committed revision 2329.
> >
> > OK, so "ci" can make the intended sense of a changelist when there
> > are changes there, though not so much when they're not.
>
>
> There's sort of a bug here, and sort of not.
>
> If you had typed 'svn commit src src/foo.c', and there were no local
> edits to commit, I would expect nothing to happen. Commit returns 0,
> it's a no-op.
>
> However, it looks like you found a buglet... I think the existence of
> the directory path in the changelist *and* lack of changes to commit
> caused the commit codepath to error weirdly.
>
>
> > Then there's the behavior of auto-removal from a changelist. If you
> > commit a change, the item is removed from any change list where it
> > might reside; good so far. But if you commit the changelist, and it
> > contains some unmodified objects, they are not removed from the
> > change list.
>
> Yes, the design doc explictly states that "being a member of a
> changelist" and "having local mods" are completely orthogonal things.
> They have no effect on each other.
Well, sure, but if they're orthogonal (which makes sense), then
whether or not something has local mods shouldn't affect the behavior
of
$ 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!
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.
--dave
--
David Glasser | glasser@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
Re: overlapping change lists?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 10/5/07, Jack Repenning <jr...@collab.net> wrote:
> There was some discussion, a while back, about overlapping change
> sets. A perhaps over-brief summary seems to be:
>
> > Several people wanted them well-managed, but Ben didn't think the
> > problem was worth attention, so none was given it.
Well, this isn't exactly fair. :-) It's not that the problem isn't
worth attention -- I would *love* to see it. But you have to take
small steps. The design doc explicitly states overlapping changelists
as a non-goal:
A number of people ask "but what if two different changes within a
single file belong to different logical changes?" My reply is:
either "tough luck" or "don't do that" or "checkout a separate
working copy". My feeling is that trying to create a UI to
manipulate individual diff-hunks within a file is a HUGE can of
worms, probably best suited for a GUI. While I wouldn't rule it
out as a future *enchancement* to a changelist feature, it's
certainly not worth the initial effort in the first draft of
changelist management. Overlapping changelists do occasionally
happen, but they're rare enough that's it's not worth spending 90%
of our time on a 10% case -- at least not in the beginning.
IIRC, I don't think anyone disagreed with my scaled-down goals at the
outset, other than cmpilato. If folks would like to work on
hunk-management for overlapping changesets in 1.6, that would be super
cool! It's a big task.
> Some details of the implementation actually prevent overlaps (for
> example, a given target can be in at most one changelist). But
> overlaps are not completely prevented, and the system behavior when
> they do arise is very surprising.
I think there's a misunderstanding here: overlaps *are* completely
prevented. As you say: a path can only belong to one changelist at a
time. The confusion here comes from the unusual case of adding a
directory to a changelist: what does that mean? Your (totally
reasonable) assumption is that it's a depth-infinity operation. The
reality is that it's a depth-0 operation, just as with files. The
only reason we allow directories to be members of changelists is so
that we can commit property-changes to them, just like when we do 'svn
commit -N dir'.
Re: overlapping change lists?
Posted by Jack Repenning <jr...@collab.net>.
On Oct 5, 2007, at 6:04 PM, Ben Collins-Sussman wrote:
> I'll reply in a bit; but yes, the fundamental problem here is that
> nobody has ever tried to put a directory into a changelist before --
> it simply wasn't part of the design, and wasn't tested.
In that case, I'd probably settle for having "svn changelist
TARGET..." ignore directory args. I could dream of grander kinds of
support, but I feel a slippery slope of Himalayan proportions looming.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: overlapping change lists?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I'll reply in a bit; but yes, the fundamental problem here is that
nobody has ever tried to put a directory into a changelist before --
it simply wasn't part of the design, and wasn't tested.
On 10/5/07, David Glasser <gl...@davidglasser.net> wrote:
> The following is some really good points.
>
> Ben, what are the semantics of putting a directory on a changelist
> supposed to be? (This is what many of Jack's points relate to, though
> not all.)
>
> --dave
>
> On 10/5/07, Jack Repenning <jr...@collab.net> wrote:
> > There was some discussion, a while back, about overlapping change
> > sets. A perhaps over-brief summary seems to be:
> >
> > > Several people wanted them well-managed, but Ben didn't think the
> > > problem was worth attention, so none was given it.
> >
> > Some details of the implementation actually prevent overlaps (for
> > example, a given target can be in at most one changelist). But
> > overlaps are not completely prevented, and the system behavior when
> > they do arise is very surprising. Frankly, having just stumbled onto
> > these quirks, I'm feeling like they're an embarrassment to the entire
> > product, and shouldn't be allowed out the door. But I might be
> > overreacting. Examples:
> >
> > $ svn changelist l1 src src/foo.c
> > $ svn changelist l2 src/bar.c
> >
> > Question: is bar.c in list l1? Opinion differs:
> >
> > $ echo >> src/bar.c
> >
> > $ svn stat
> > --- Changelist 'l1':
> > src
> > src/foo.c
> >
> > --- Changelist 'l2':
> > M src/bar.c
> >
> > Guess not. But:
> >
> > $ svn diff --changelist l1
> > Index: src/bar.c
> > ===================================================================
> > --- src/bar.c (revision 2326)
> > +++ src/bar.c (working copy)
> > @@ -21,3 +21,4 @@
> > }
> > sleep(1);
> > }
> > +
> >
> > Oh, guess it is. But:
> >
> > $ svn ci -mx --changelist l1
> > svn: Unknown changelist 'l1'
> >
> > "Unknown"? Even "stat" at least knows of this changelist, though it
> > shows no changes therein, what's this "unknown" business? OK, let's
> > try:
> >
> > $ echo >> src/foo.c
> > $ svn ci -mx --changelist l1
> > Sending src/foo.c
> > Transmitting file data .
> > Committed revision 2329.
> >
> > OK, so "ci" can make the intended sense of a changelist when there
> > are changes there, though not so much when they're not.
> >
> > Then there's the behavior of auto-removal from a changelist. If you
> > commit a change, the item is removed from any change list where it
> > might reside; good so far. But if you commit the changelist, and it
> > contains some unmodified objects, they are not removed from the
> > change list. I can think of some workflows where that makes sense,
> > like "I need to make a related change to all these files, but I'll
> > commit them in chunks, say because I like to commit once a day." But
> > I could also tell that tale as "I need to make this change to all the
> > files in this directory, so I put the directory into the change list,
> > but hey, it never gets autoremoved because I'm not actually changing
> > the directory." The feature implements a certain workflow, but not
> > others, yet there seems no guidance on what to expect.
> >
> >
> > -==-
> > Jack Repenning
> > Chief Technology Officer
> > CollabNet, Inc.
> > 8000 Marina Boulevard, Suite 600
> > Brisbane, California 94005
> > office: +1 650.228.2562
> > mobile: +1 408.835.8090
> > raindance: +1 877.326.2337, x844.7461
> > aim: jackrepenning
> > skype: jrepenning
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >
> >
>
>
> --
> David Glasser | glasser@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
Re: overlapping change lists?
Posted by David Glasser <gl...@davidglasser.net>.
The following is some really good points.
Ben, what are the semantics of putting a directory on a changelist
supposed to be? (This is what many of Jack's points relate to, though
not all.)
--dave
On 10/5/07, Jack Repenning <jr...@collab.net> wrote:
> There was some discussion, a while back, about overlapping change
> sets. A perhaps over-brief summary seems to be:
>
> > Several people wanted them well-managed, but Ben didn't think the
> > problem was worth attention, so none was given it.
>
> Some details of the implementation actually prevent overlaps (for
> example, a given target can be in at most one changelist). But
> overlaps are not completely prevented, and the system behavior when
> they do arise is very surprising. Frankly, having just stumbled onto
> these quirks, I'm feeling like they're an embarrassment to the entire
> product, and shouldn't be allowed out the door. But I might be
> overreacting. Examples:
>
> $ svn changelist l1 src src/foo.c
> $ svn changelist l2 src/bar.c
>
> Question: is bar.c in list l1? Opinion differs:
>
> $ echo >> src/bar.c
>
> $ svn stat
> --- Changelist 'l1':
> src
> src/foo.c
>
> --- Changelist 'l2':
> M src/bar.c
>
> Guess not. But:
>
> $ svn diff --changelist l1
> Index: src/bar.c
> ===================================================================
> --- src/bar.c (revision 2326)
> +++ src/bar.c (working copy)
> @@ -21,3 +21,4 @@
> }
> sleep(1);
> }
> +
>
> Oh, guess it is. But:
>
> $ svn ci -mx --changelist l1
> svn: Unknown changelist 'l1'
>
> "Unknown"? Even "stat" at least knows of this changelist, though it
> shows no changes therein, what's this "unknown" business? OK, let's
> try:
>
> $ echo >> src/foo.c
> $ svn ci -mx --changelist l1
> Sending src/foo.c
> Transmitting file data .
> Committed revision 2329.
>
> OK, so "ci" can make the intended sense of a changelist when there
> are changes there, though not so much when they're not.
>
> Then there's the behavior of auto-removal from a changelist. If you
> commit a change, the item is removed from any change list where it
> might reside; good so far. But if you commit the changelist, and it
> contains some unmodified objects, they are not removed from the
> change list. I can think of some workflows where that makes sense,
> like "I need to make a related change to all these files, but I'll
> commit them in chunks, say because I like to commit once a day." But
> I could also tell that tale as "I need to make this change to all the
> files in this directory, so I put the directory into the change list,
> but hey, it never gets autoremoved because I'm not actually changing
> the directory." The feature implements a certain workflow, but not
> others, yet there seems no guidance on what to expect.
>
>
> -==-
> Jack Repenning
> Chief Technology Officer
> CollabNet, Inc.
> 8000 Marina Boulevard, Suite 600
> Brisbane, California 94005
> office: +1 650.228.2562
> mobile: +1 408.835.8090
> raindance: +1 877.326.2337, x844.7461
> aim: jackrepenning
> skype: jrepenning
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
--
David Glasser | glasser@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