> I find this very intuitive, and it could lead to some trouble when
> updating to svn 1.2. I would only expect the diff command to follow
> renames (only between the two given revisions), not all the other
> commands. Commands that only address a single revision (like ls,
> checkout, copy ..) should not follow renames from head to the given.
> This rename tracking should be the exception for commands that need it
> (maybe diff, merge), not the rule.
> It might be too late for these discussions (I have not followed the dev
> list), but look at situations like this that might make this feature
> annoying (at least for checkout commands)
For the most part, yes it is too late. This was mostly a 1.1 feature.
There were only a small number of commands like cat that did not get this
feature until 1.2. I disagree with you and think you are overreacting.
For every scenario you can come up with where you do not think this makes
sense, myself or someone else could come up with one where it does make
sense. Also, the lack of this feature has caused problems for GUI clients.
Subclipse and TortoiseSVN both have a problem today because we use cat to
get an old revision to feed to a source compare and the cat command fails
if the file has been moved. If the command followed the history back from
HEAD, as it does in 1.2, it would work.
We can argue all day about what the default should be, but the point is
that there has to be some kind of default behavior. The question is do you
have one default that applies to all commands, or do you have a different
default for each command. The devs chose the former, which seems logical
to me. I also happen to agree that HEAD is the correct default, but there
is no real point in having that conversation.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Mar 10 02:43:56 2005