On Tue, Mar 30, 2010 at 03:21:45PM -0400, C. Michael Pilato wrote:
> Vincent Lefevre wrote:
> > On 2010-03-30 12:12:59 -0400, C. Michael Pilato wrote:
> >> Interactions in the working copy with the path some/file.c only make sense
> >> if there is actually such a path in the working copy. If some/file.c is
> >> deleted in r51, then either it isn't in your working copy (because you've
> >> updated past r50) or it is, at r50 or earlier. If it is, you run 'svn cat
> >> some/file.c' as usual. If it isn't, then the path 'some/file.c' has no
> >> meaning anyway, so it falls to you to spelunk history and tell Subversion
> >> more precisely what object you're talking about.
> >
> > I want a simple way to say: consider the current directory at r50
> > (walking back through the history) and the object some/file.c in
> > it at the same revision.
>
> I'm sure you're not alone, but Subversion doesn't cleanly provide such a way
> today.
>
> $ svn cat `svn info some/ -r50 | grep ^URL: | cut -c 6-`/file.c_at_50
Maybe we could some day extend peg revision syntax so that every
component of a path can be pegged?
So what Vincent wants would be something like this:
$ svn cat ._at_50/some/file.c
And make svn treat a double-@ as actual @:
$ ls
dir_at_example.com
$ svn cat dir@@example.com/file.c
On the surface, this would be a natural extension to the current peg
rev syntax, which only looks for @ at the very end of the entire path.
Whoever actually does this should be well prepared for some serious
wrestling with the current APIs though... this would not be a simple
change. I guess it would easily size up to at least a google summer
of code project.
Stefan
Received on 2010-03-30 21:37:02 CEST