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
