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

[Kevin Musker]

--- Giovanni Bajo <rasky at develer.com> wrote:

> 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
> 

Hi Giovanni,

Thanks for your response.


The definitions of {get,strip}_peg are a lot more
concise :)


The need for strip_peg arises because svn log doesn't
support it in v1.3.2. It instead seems to infer a peg
revision from the upper value specified in -r.

For instance, when you run 'svn log <file>', it is
equivalent to running 'svn log -r1:HEAD <file>'. This
will give you the log of <file> from HEAD, back as far
as it can gather log information (oldest rev. first).

If you specify different revisions, such as 'svn log
-r1:1234 <file>', this will give you the log of the
object <file>, as it was at revision 1234, back as far
as it can. This seems to be analogous to specifying a
peg revision.

In an example:

r122 : create and add a file called file.txt,
containing the word 'dog'.
r123 : changed file.txt contents to be 'cat'
r124 : remove the file called file.txt
r125 : create and add a file file.txt, containing the
word 'giraffe'
r126 : changed file.txt contents to be 'monkey'

a) If you run 'svn log file.txt' or 'svn log -r1:HEAD
file.txt', you will get revisions 125-126.
b) If you run 'svn log -r1:123 file.txt', you will get
revisions 122-123.
c) If you run 'svn log -r1:124 file.txt', you will
receive a File not found error.


I have been able to test it with svn v1.4.3, and my
changes don't work :(

In this version, giving svn log a peg revision does
seem to work. In the above example, running 'svn log
file.txt@<rev>' on v1.4.3 yields the same as 'svn log
file.txt -r1:<rev>' on v1.3.2.
In v1.4.3, examples a & c work as above. Example b
would require the specification of the perg revision a
la 'svn log -r1:123 file.txt at 123.

This behaviour is described here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&&msgNo=102422
The behaviour or 1.3.2 is deemed a bug.

1.4 acts a little wierd if you specify -r1:HEAD and a
peg. In this case, the peg is ignored and it returns
the log of the object existing at HEAD.

This means that the code should work if the operation
of strip_peg is made conditional on the installed
version of svn.

I haven't been able to test on 1.5.x though.

Thanks,

Kev.


      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/