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."
But that example shows a trivial use of changelists -- just one or two
files, one commit.
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.
> Is it possible that printing unmodified items in a changelist was a
> deliberate design decision way back when the changelist features came
> to light, and we simply forgot?
Quite possible; and we haven't necessarily forgotten, just re-visiting it.
> We could say that 'svn status' by default only prints files that are
> "interesting" (for some definition of "interesting") and the virtue of
> being associated to a changelist makes a file "interesting" whether
> it's modified or not. ???
It seems only to make sense in trivial uses of changelists, and not when
tracking lots of files over many commits.
- Julian
Received on 2019-11-08 14:00:39 CET