[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Command line repository root relative URLs

From: Troy Curtis Jr <troycurtisjr_at_gmail.com>
Date: 2007-10-21 00:31:28 CEST

== The Plan ==
So I plan to put code where my mouth is and add support for repository
root relative URLs. I will be basing the parsing on Blair's recent
relative-externals commits, though I am not planning on implementing
scheme relative, server relative, or general relative URLs (i.e.
'../').

For consistency, I am planning on using the same syntax used in
relative-externals, namely "^/path/in/repo". There was some
discussion related to the fact that '^' is technically a valid
filename character. It was also mentioned (and I agree) that '^' is
basically never seen in a real-world filename and so should be OK to
use for my purpose. Also, treating characters specially that are also
valid characters in filenames is not un-precedented since every shell
does it (i.e $, `, etc.).

That said Subversion should certainly be able to support filenames
containing '^'. What I propose is the we only treat arguments
containing '^/' as the first two characters specially. That was '^'
could occur anywhere else in path and can precede any other character
without special interpretation. Also no special escaping needs to be
supported since doing './^/rest/of/path' would not be treated
specially.

The intent here is for this to be a VERY convenient short cut when
dealing with "full" URLs. I suppose that we could come up with
some alternate syntax for supporting the "../" relative URLs but I
think it would be much less useful in practice. I know from using
*nix shells that keeping track of how many '../' you've typed and
knowing how many you need is not always easy. Without tab-completion
it is nearly impossible IMHO! :)

Please vote as to whether you like this idea or not, if it's popular
enough maybe some of the "real" Subversions devs will help me along on
my quest!

== The Gory Details ==
First the disclaimer: I know the general structure of the Subversion
code-set (I looked through it when learning to use some of the
perl-bindings) but I do not have in-depth knowledge of it, or with
using APR. Therefore I do need a little help in determining the best
place to put this.

My first thought is to put it in the svn_opt_args_to_target_array2()
function located in subversion/libsvn_subr/opt.c. I can put a check
for '^/' in right before svn_path_is_url() in line 859. This appears
to be a very easy place to implement it as it will transparently
translate '^/.....' URLs to full URLs. However, the problem with that
location is that I don't have the repository root URL immediately
available to me. Plus it appears that the function doesn't parse the
peg revision syntax, even though the previous version did do so. I
presume this means it was changed for a reason (i.e. the function was
doing too much).

My next thought is to create a new function taking as an example the
fact that svn_opt_parse_path() was apparently factored out of
svn_opt_args_target_array() for a reason. Of course this means I will
have to touch more files to make sure all the commands call this
function to support the new syntax.

Or perhaps a successor to svn_opt_args_to_target_array2():
svn_opt_args_to_target_array3() which has the repository root as an
optional argument?

My investigation continues and would love to hear thoughts on
implementation as I fumble my way through the Subversion source tree
:).

Troy

-- 
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 21 00:31:36 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.