A concern regarding the changelist feature

MICHAEL HAGGARTY MAKES WHAT I THINK IS A VALID COMPLAINT
ABOUT THE NEW
'CHANGELIST' FEATURE IN, ODDLY ENOUGH, A BLOG COMMENT.  YOU
CAN READ IT HERE:

HTTP://BLOGS.OPEN.COLLAB.NET/SVN/2007/07/ONE-QUALITY-OF-.HTM
L#COMMENT-84263984

FOR YOUR CONVENIENCE, I'LL REPRODUCE COMMENT HERE:

POSTED BY: MICHAEL HAGGERTY | SEPTEMBER 27, 2007 AT 08:13
AM
> > $ SVN CL FOO PLAZA.JPG
> > PATH 'PLAZA.JPG' IS NOW A MEMBER OF CHANGELIST
'FOO'.
> > $ SVN CL BAR PLAZA.JPG
> > PATH 'PLAZA.JPG' IS NOW A MEMBER OF CHANGELIST
'BAR'.
> > $ ...
>
> YIKES, THERE IS NO ERROR OR WARNING IF YOU MOVE A FILE
FROM ONE
> CHANGELIST TO ANOTHER? THIS SOUNDS LIKE TROUBLE. IF
I'VE MODIFIED A
> FILE AS PART OF CHANGELIST A, THEN (FORGETTING
CHANGELIST A) ADD IT
> TO CHANGELIST B, THEN COMMIT CHANGELIST A, THEN MY
COMMIT IS
> PROBABLY BROKEN.
>
> WHAT WOULD BE REALLY SWEET WOULD BE A WAY TO STASH A
SELECTED
> CHANGELIST AWAY SOMEWHERE (E.G., AS A PATCH) AND
UNAPPLY THE
> CORRESPONDING CHANGES FROM THE WORKING COPY. THIS WOULD
ALLOW ME TO
> TEST A SPONTANEOUS MINI-FIX BEFORE COMMITTING IT,
WITHOUT HAVING TO
> WORRY THAT THE "MAIN" WORK-IN-PROGRESS IS
AFFECTING THE RESULTS MY
> UNIT TESTS (THE MAIN WORK-IN-PROGRESS MIGHT PREVENT MY
CODE FROM
> EVEN COMPILING AND/OR RUNNING, OR EVEN WORSE, THE
MINI-FIX MIGHT
> WORK *ONLY* BECAUSE OF CHANGES MADE IN THE
WORK-IN-PROGRESS).
>
> I'VE BEEN WORKING WITH QUILT A LOT LATELY, AND
APPRECIATE ITS
> ABILITY TO APPLY/UNAPPLY PATCHES EASILY. WITH QUILT, IT
IS EASY TO
> "POP" THE MAIN WORK-IN-PROGRESS FROM THE
STACK OF APPLIED PATCHES,
> IMPLEMENT THE QUICK FIX, TEST, COMMIT, THEN
"PUSH" THE MAIN PATCH
> BACK ONTO THE WORKING COPY. THE SVN CHANGELIST CONCEPT
IS OBVIOUSLY
> SOMEWHAT DIFFERENT THAN QUILT'S MODEL (FOR EXAMPLE,
QUILT IMPOSES A
> LINEAR ORDERING OF THE PATCHES UNDER ITS CONTROL), BUT
THE ANALOGY
> COULD NEVERTHELESS BE USEFUL.
>
> "STASHABLE" CHANGELISTS WOULD ALSO BE A WAY
TO ALLOW A SINGLE FILE
> TO PARTICIPATE IN MULTIPLE CHANGELISTS AT THE SAME
TIME, PROVIDED
> ALL BUT ONE OF THE CHANGELISTS IS "STASHED"
AWAY. WELL, I GUESS THAT
> ISN'T REALLY "AT THE SAME TIME", BUT RATHER
"IN QUICK ALTERNATION"
> 

-- 
C. MICHAEL PILATO <CMPILATOCOLLAB.NET>
COLLABNET   <>   WWW.COLLAB.NET   <>  
DISTRIBUTED DEVELOPMENT ON DEMAND

On 9/27/07, C. Michael Pilato <cmpilatocollab.net> wrote:
> Michael Haggarty makes what I think is a valid
complaint about the new
> 'changelist' feature in, oddly enough, a blog comment. 
You can read it here:
>
> http://blogs.open.collab.net/svn/2
007/07/one-quality-of-.html#comment-84263984
>
> For your convenience, I'll reproduce comment here:
>
> Posted by: Michael Haggerty | September 27, 2007 at
08:13 AM
> > > $ svn cl foo plaza.jpg
> > > Path 'plaza.jpg' is now a member of
changelist 'foo'.
> > > $ svn cl bar plaza.jpg
> > > Path 'plaza.jpg' is now a member of
changelist 'bar'.
> > > $ ...
> >
> > Yikes, there is no error or warning if you move a
file from one
> > changelist to another? This sounds like trouble.
If I've modified a
> > file as part of changelist A, then (forgetting
changelist A) add it
> > to changelist B, then commit changelist A, then my
commit is
> > probably broken.

"Moving a file from one changelist to another" was
one of our original
use-cases when designing the changelist UI.  Nobody in the
discussion
thought that this use-case was a mistake worthy of a
warning/error,
but rather as something deliberate that a user might want to
do.  So,
in the final UI design, we kept things tight and overloaded
'svn cl
file changelist' as satisfying both "add a file to a
changelist" and
"move a file to a new changelist" use-cases. 
Here's the UI, for those
who aren't aware:

1. add path(s) to a CL:

     svn cl CLNAME foo.c bar.c baz.c

2. remove path(s) from whatever CLs they each belong to.

     svn cl --remove foo.c bar.c baz.c

3. move path(s) from CL1 to CL2.

     svn cl CL2 foo.c

4. undefine a CL all at once (by removing all members)

     svn cl --remove --changelist CLNAME

5. rename a CL

     svn cl NEWNAME --changelist OLDNAME


Maybe an improvement to the UI would be to change the text
to point
out that the file being moved *was* a member of a previous
changelist:

  "Path 'foo' has moved from changelist 'bar' to
changelist 'baz'."

??


> >
> > What would be really sweet would be a way to stash
a selected
> > changelist away somewhere (e.g., as a patch) and
unapply the
> > corresponding changes from the working copy.

?

$ svn diff --changelist foo > foo.patch
$ svn revert --changelist foo

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

Yes the suggestion does smell a little like a weak
implementation of
local branches...

That doesn't invalidate the argument that a changelist is a
set of
changes that should go together and that moving a change
intended for
one commit into another silently does sound like broken
workflow - the
user should absolutely be warned as it's clearly going to be
easy to
do accidentally if you have two large and complicated
changelists in
play.

I'd consider throwing an error for a move to a new
changelist and
providing a --force option to make it happen.

--
Talden

On 10/1/07, Tor Ringstad <torhrpvv.org> wrote:
> [Michael Haggerty]
> > What would be really sweet would be a way to stash
a selected
> > changelist away somewhere (e.g., as a patch)
[...]
>
> Aren't these "advanced changelist" features
just branches in disguise?
>
>
> - Tor -
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
> For additional commands, e-mail: dev-helpsubversion.tigris.org
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

C. Michael Pilato wrote:
> Michael Haggarty makes what I think is a valid
complaint about the new
> 'changelist' feature in, oddly enough, a blog comment. 
You can read it here:
> 
> http://blogs.open.collab.net/svn/2
007/07/one-quality-of-.html#comment-84263984
> 
> For your convenience, I'll reproduce comment here:
> 
> [...]

At the request of some people on IRC, I created issues #2947
and #2948
covering the two points mentioned in my blog comment:

http://subversion.tigris.org/issues/show_bug.cgi?id=2947

http://subversion.tigris.org/issues/show_bug.cgi?id=2948


Ben Collins-Sussman wrote:
> Maybe an improvement to the UI would be to change the
text to point
> out that the file being moved *was* a member of a
previous changelist:
>
>   "Path 'foo' has moved from changelist 'bar' to
changelist 'baz'."
>
> ??

Yes, that would be fine.  As long as it is not silent, then
I'm happy.

>>> What would be really sweet would be a way to
stash a selected
>>> changelist away somewhere (e.g., as a patch)
and unapply the
>>> corresponding changes from the working copy.
>
> ?
>
> $ svn diff --changelist foo > foo.patch
> $ svn revert --changelist foo

That's handy; I hadn't realized that revert allows a
--changeset option.

But it is still requires a lot more manual bookkeeping (and
is therefore
more error prone) than

$ quilt pop

which I use about 50 times a day along with its friend,
"quilt push". 

Michael

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

[Michael Haggerty]
> But it is still requires a lot more manual bookkeeping
(and is therefore
> more error prone) than
> 
> $ quilt pop
> 
> which I use about 50 times a day along with its friend,
"quilt push". 

Nobody ever said you couldn't use quilt inside a svn working
copy.  If
you're working on multiple features and don't want multiple
WCs, it
might not be a bad arrangement.  quilt seamlessly handles
multiple
changesets that touch the same file, something svn
changelists will
never be good at.

The chief annoyance with quilt is that you have to warn it
that you
intend to edit a file.  (See related flamage in the p4
thread a few
days ago.)  If quilt could detect that it's in a svn working
copy, it
could avoid the need for this, as the pristine files are
already
available (using 'svn cat' if nothing else).

Hmmm.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/