Julian Foad wrote on Fri, 08 Nov 2019 13:00 +00:00:
> Nathan Hartman wrote:
> > > Friday% svn st -q
> > > --- Changelist 'foo':
> > > M iota
> > > Friday% vi A/mu
> > > Friday% svn commit -mm --cl foo
> > > Sending iota
> > > Sending A/mu
> > > # ... "Revert accidental commit"
> >
> > You're right. That would be immensely irritating...
>
> The opposite reading of that example is,
> # "Oh! I'm glad I used a changelist. I had forgotten both files were
> in my changelist and I would have accidentally omitted one from the
> commit if I had specified a filename instead of a changelist."
I agree that changelists can have a gladdening effect in some cases, but
that example isn't one of them. In that example, the user had to revert
an accidental commit. He hadn't been gladdened.
The intended reading of the example is that after exiting vi, the user
reviewed the output in the terminal, assumed that A/mu wasn't in any
changelist, wanted to commit iota, and was surprised by the fact that
'commit --cl foo' committed not only iota but also A/mu.
> But that example shows a trivial use of changelists -- just one or two
> files, one commit.
The example output showed just 'iota' because it was a minimal example.
There might have been any number of files in the 'foo' changelist and
modified, and the user wanted to commit all of them but not A/mu.
> In my example, I have about 60 files in one changelist and 20 in each of
> three more changelists, and it makes sense to keep these changelist
> assignments over a series of commits over many weeks. In each commit I
> only touch one or a few files.
>
> That changes things. I frequently want to check what files I have
> changed. I don't need or want to keep seeing my changes interspersed in
> a screenful of blank output. I don't need constant reminding of the
> changelist assignments of all my hundred-and-twenty files when I'm just
> looking to see what's ready for commit.
It certainly does change things. You describe a use-case in which
changelists are effectively permanent fixtures of a working copy, or
possibly even of several related working copies (e.g., different
branches of a single project). That's an interesting use-case, but I don't
think it was envisioned when changelists were introduced, so it's no
surprise that there's some impedance mismatch between the implemented
and desired functionalities.
Thinking out loud:
I wonder if we should invent some notion of "quiet" changelist, i.e.,
a changelist whose files aren't shown in 'status' output if they're
unmodified. Effectively, we'd have one bit of metadata for each
changelist; changelists that have the bit set would have the behaviour
Julian proposed; and other changelists would continue to have the current
behaviour. (I deliberately leave unspecified for the time being the
question of how we'd set, unset, and query that bit.) The output could
look like this:
[[[
# Default: loud changelist
% svn st
--- Changelist 'foo':
lorem
M ipsum
%
⋮
# New behaviour: silent changelist
% svn st
--- Silent changelist 'foo' (42 files not shown):
M ipsum
%
]]]
Furtheromre, I wonder if we should allow to configure changelists via
properties, somehow. For example, we might have «svn ps svn:changelists
"foo: subversion/svn/svn.c subversion/svnserve/svnserve.c …
subversion/svnsync/svnsync.c" ./» and then do «svn st --cl :foo» to
query the cmdline binaries' entry point C files.
Daniel
Received on 2019-11-08 14:28:56 CET