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-`/fil...@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 ....@50/some/file.c And make svn treat a double-@ as actual @: $ ls d...@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
