On 20/07/11 10:07, Michael J Gruber wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html