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

Re: RFC: Untangling the peg revision knot (was: A preliminary study of non-contiguous transformations in the Hilbert space of Alexandrian solutions)

From: Branko Čibej <brane_at_xbc.nu>
Date: Wed, 26 Nov 2008 20:51:53 +0100

Mark Phippard wrote:
> On Wed, Nov 26, 2008 at 2:31 PM, Branko Čibej <brane_at_xbc.nu> wrote:
>> (The usual way to get both URL and REV are to do an svn log -v, find the
>> set of commits you're looking for, and copy rev and path from there,
>> never caring about later deletions or renames or whatnot.)
> Sorry, but I am still in disagreement. Your example just further
> solidifies that. Let's use your example. I am naturally working in
> HEAD and I run svn log -v to look at history. I see some old
> interesting revision that I want to see more details about. You now
> want me to also notice that somewhere in the history of the item the
> name of the item has changed and use that new name when I use
> subsequent commands. I'd typically assume the filename had not
> changed and would get a failure.

Huh? You've turned my explanation inside out. I said you get the *old*
path and rev from the log, and do

    svn co -r rev URLBASE/path

Dunno, maybe that boils down to a syntactic issue, as it appears that at
least for URLs, the @PEG syntax would be used more often than -r. That
in and of itself is wrong.

Consider, e.g., "svn log -r A:B URL"; why should I write that as "svn
log -r A:B URL_at_A" if it should be obvious from context that this is the
most likely interpretation? Same for the "svn log" -> "svn log ._at_HEAD" case.

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-26 20:52:12 CET

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.