[Svnmerge] Possible enhancement to allow merging from (re)moved paths

[Giovanni Bajo]

On 11/22/2007 3:22 PM, Kevin Musker wrote:

> At first, I thought that after the move, we'd just
> need to update the svnmerge properties to reference
> the new structure, and it would all be fine.
> Unfortunately (and obviously, after closer inspection)
> this doesn't work as the new structure didn't exist in
> the past.
> 
> So, I've created a potential patch to allow the use of
> peg revisions to specify exactly what the merge source
> is refering to.
> 
> It seems to work properly for our purposes, but I'm
> not familair with all the possible uses of svnmerge.
> I've included a unit test to demonstrate intended use.
> 
> This is my first foray into the world of python, so
> there may well be a better way of doing this...
> 
> Patch for svnmerge.py:
>     http://pastebin.com/m74720440
> 
> Patch for svnmerge_test.py:
>     http://pastebin.com/m5141bc49

Hi Kevin,

many thanks for the patch. We went through this before, but back at that 
time SVN did not accept peg revisions in some basic command that was 
required for proper operation (I don't remember which one).

Besides the Python-ization of a couple of things (eg:

def get_peg(s):   return s.rsplit('@',1)[1]
def strip_peg(s): return s.rsplit('@',1)[0]

), I'm a little concerned about the uses of strip_peg. Why are those 
required? I fear that "URL at REV" and "URL" might point to different 
objects in the timeline. Eg: In r1, I have /A and /B. In r10, I rename 
/B into /A, and /A into /B. Then "/A at 1" and "/A" are two different objects.

So, basically, "URL at REV" (for whatever rev) is just a way to identify a 
specific object: instead of calling it by the name it has at the HEAD 
revision, you call it by the name it used to have at a specific 
revision. Thus, strip_reg() shouldn't ever be required, especially in 
the context of an external invokation of "svn".
-- 
Giovanni Bajo