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 <glasser@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 <jrepenning@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_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 Sat Oct 6 03:04:37 2007