Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@<rev>' syntax

From: Sam Vilain <sam@vilain.net>
Date: Jul 20, 2011, 16:59 UTC
Message-ID: <4E27098B.906@vilain.net>
In-Reply-To: <4E269AB6.8070207@drmicha.warpmail.net>

On 20/07/11 10:07, Michael J Gruber wrote:

Show 18 quoted lines

> path@REV are so-called peg revisions, introduced in svn 1.1, and denote
> "I mean the file named path in REV" (as opposed to "the file named path
> now and maybe differently back then"). It (now) defaults to BASE (for
> worktree) resp. HEAD (for URLs). A bit like our rename detection.
>
> -r REV specifies the operative revision. After resolving the
> name/location using the pegrev, the version at the resolved path at the
> oprative version is operated on.
>
> svn 1.5.0 (June 2008) introduced peg revisions to "svn copy", so I
> assume our people were following svn trunk and adjusting in 2007 already
> (to r22964). There were some fixes to "svn copy" with peg later on.
>
> I do not understand the above commit message at all; and I did not find
> anything about how "svn copy -r REV" acted in svn 1.4. I would assume
> "operative revision", and the above commit message seems to imply that
> peg defaulted to REV here (not HEAD) and that that changed in 1.5.0, but
> that is a wild guess (svnbook 1.4 does not so anything).

What happened is that I noticed that the code stopped working after svn 1.5 was released. Previously I wrote it to detect the merge properties as left by SVK and the experimental/contrib python script for merging. I was testing at times using trunk SVN versions. You could probably figure it out by running ffab6268^ with svn 1.4.x vs svn 1.5.x if you cared. My comment tries to explain what you describe above, but without the correct terms. I could see via experimentation what the difference was between "-r N" and '/path@N', and that the behaviour changed in svn 1.5. Apologies for not explaining this thoroughly enough in the submitted description!

HTH, Sam