I have been working a little bit on trying to get all commands to
accept peg revisions and do history tracing, and have run into some
interesting consequences of the current default value of the peg
revision. I am going to explain the problem I saw, describe how peg
revisions work currently, propose some alternatives, and see what
everyone thinks. Hopefully we can all be on the same page for how peg
revisions should operate in 1.2.
The main weirdness I found applies if existing repositories have
"tagged" an external by using the -r rev option. Using a default peg
revision of HEAD for URLs could actually mean that the resource
checked out in the external would change if someone deleted and
recopied a new path over the existing one in HEAD. All existing
externals using that feature would have to be rewritten to use the
"URL@rev" syntax in order to have the same functionality.
There have also been several complaints about the new syntax on the
list, although most of them have been about the changing behavior
between versions and not about the merits of the syntax itself. The
complaints have come rarely enough though, that I am not sure of the
number of developers who care one way or another.
Currently, the existing peg revision syntax works as follows for all
commands (except copy & checkout which have not been implemented yet).
Any URL may contain an optional @rev specify at the end of the URL.
This revision is the actual revision where the URL is first looked up
in the repository. Then, history tracing is used to find the location
of the resource(s) in the repository to operate on for the command
itself. The default peg revision is HEAD for URLs, and BASE for
working copy targets.
Other sane default values exist. One other sensible method is to have
the peg revision default to the last revision specified in the given
command. 'svn diff -rx:y URL' would peg at y, 'svn cat -r x foo',
would peg at x and do no history tracing at all, and 'svn cat URL'
would peg at HEAD and also do no history tracing. A third option
would be to perform no history tracing whatsoever unless a '@'
specifier was provided.
Thoughts?
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 12 13:42:10 2004