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 00:56:56 2007