Thanks for looking at the changelist design doc! Others, please join
in and give feedback as well!
On 6/28/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Tue, Jun 27, 2006 at 09:52:00AM -0700, sussman@tigris.org wrote:
> > +B. Viewing changelists
> > +
> > +'svn status' currently shows changelist definitions by crawling the
> > +working copy. Output is much more readable than perforce, because
> > +we're still preserving column alignment:
> > +
> > +$ svn st
> > +? 1.2-backports.txt
> > +M notes/wc-improvements
> > +
> > +Changelist 'status-cleanup':
> > +M subversion/svn/main.c
> > + subversion/svn/revert-cmd.c
> > +M subversion/svn/info-cmd.c
> > +
> > +Changelist 'status-printing':
> > +M subversion/svn/status-cmd.c
> > +
>
> Isn't this a significant change to our existing output? Anyone who has
> a script to look for Conflicted entries, for example, will now see the
> changelist headers as conflicting.
>
> I thought we'd discussed adding a switch to show changelist membership
> for status?
Yes, I know that at least dlr proposed it. I haven't implemented it
yet (though I have implemented the output above already.) It wasn't
clear to me that any other people wanted 'svn status' to not show
changelists unless explicitly asked. My personal feeling is that 'svn
status' should *always* show changelists, and that if you're worried
about breaking an existing output-parsing script, then just don't
create changelists in the first place! If you ignore the new
changelist feature, then 'svn status' will still look the same.
By the way, this is the same philosophy we had when implementing the
locking feature: if you don't use locks, commandline output remains
unchanged. If you do use locks, then new codes appear in 'svn
status/info/etc.' that might confuse old scripts.
The reason I like this philosophy is because old things only break
*if* you start using new features. It feels like the right balance
between allowing new features and maintaining backward compatibility.
It gives script writers a nice grace period to update their scripts,
and it doesn't automatically break scripts when users simply upgrade
their svn.
(Jonathan Gilbert: yes, it might still be a good idea to show "--
Changelist blah" in output, so that even when scripts are updated to
parse the new output, regular expressions like "^C" continue to work
nicely.)
>
> > +### Open UI question:
> > +
> > + If one's CWD is deep within a working copy, how should
> > +
> > + $ svn subcommand --changlist mychange
> > +
> > + ...behave? Should it operate on *all* members of the changelist,
> > + or only those members within the CWD (and recursively "below")?
> > +
>
> I'm not keen on the idea of traversing back to a 'working copy root',
> though I know we use this concept in one or two places. Is there
> a compelling reason not to follow the pattern that the rest of the
> application uses (of operating only on the subtree below the selected
> target).
Dlr also proposed this as well. I think it would be perfectly
justifiable to just operate on the portion of the changelist "below"
the target or CWD -- we can just claim "we're being consistent". But
my question is: is this the *best* behavior? Does it have any good
or bad ramifications? It feels a tad odd to me, since in perforce, a
changelist always refers to the entire list, regardless of CWD. One
might argue that if it's possible to say "--changelist mychange" and
get varied results based on context, then it sort of defeats the point
of defining the changelist group. On the other hand, one might argue
"don't do that, then". I'm not entirely persuaded either way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 28 17:17:24 2006