On 11/3/07, Julian Foad <email@example.com> wrote:
> Troy Curtis Jr wrote:
> > For consistency, I am planning on using the same syntax used in
> > relative-externals, namely "^/path/in/repo".
> > The intent here is for this to be a VERY convenient short cut when
> > dealing with "full" URLs. [...]
> Excellent. It seems quite a "clean" improvement to the usability of commands
> dealing with branches and tags especially.
> Some drive-by thoughts while I'm thinking them...
> What do you think should be the exact meaning of the shortcut? Something like:
> The "^" shall be substituted by the Repository Root
> of the current working directory;
> if the current working directory is not a SVN WC then throw an error.
> SVN's URL character auto-escaping shall be applied to the portion after "^/".
That is exactly the way I am currently implementing it from the
prospective of the svn CL client. However, the function that actually
does the substitution simply takes a repository root URL has an
argument so that other implementations can be easily created. Even
the svn_wc_get_absolute_url() helper function takes a working copy
path to use when determining the root url, it just so happens that all
of my uses currently set that path as ".".
> For example, if my working copy is ~/wc:
> $ cd ~/wc
> $ svn copy . ^/tags/newtag
> but not
> $ cd ~
> $ svn copy wc ^/tags/newtag
> svn: '/home/julian' is not a working copy
> svn: cannot parse URL '^/tags/newtag' # or some such error message(s)
> One could be tempted to say things like, if there's a local path involved in
> the command, then look for the repository of that as well or instead of the
> current directory. I suspect that way would lie madness but maybe current
> working directory isn't the only possible rule.
Or the other thing I thought was use the root URL of the full url
found earlier in the command-line so that:
svn cp file://some/repo/trunk/ ^/branches/1.x
would work, but again, madness :).
> It would be interesting to show a set of typical usage scenarios - tagging,
> branching, merging, listing contents, etc. - with the exact realistic commands.
I have implemented the relative urls in my own tree for everything
(that makes sense) except switch, and have already found them very
useful for 'svn ls', 'svn cp' and 'svn info' as I run through some
manual tests. In fact, I really missed it today at work where I don't
have my changes!
> Certainly I agree that restricting the syntax to begin with "^/" is the right
> way to start, as this leaves clear ways to extend it later, maybe with ".." and
> such but also things like "^<repos-nickname>/" which could be configured
> somewhere and then used from anywhere. There's no shortage of ideas around this
> theme; first the important thing is to get something solid and simple and
> useful in place.
That sound very similar to certain version control tool based on
If I can get the cmdline merge test figured out, I will be hopefully
be submitting a fully implemented, documented, and the corresponding
tests for the 'svn merge' case.
> - Julian
"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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 6 04:30:53 2007