httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: mergeinfo ignorance
Date Sun, 22 Jul 2012 14:51:27 GMT
On 22.07.2012 16:14, Jeff Trawick wrote:
> On Sun, Jul 22, 2012 at 9:48 AM,  <> wrote:
>> Author: rjung
>> Date: Sun Jul 22 13:48:30 2012
>> New Revision: 1364302
>> URL:
>> Log:
>> Add mergeinfo for backports done by jim in r1200981.
> Is there a quick guide (like a couple of sentences ;) ) to how
> mergeinfo should be managed and how it will be used?  I am most likely
> part of the problem with this, but I don't know the goals/mechanisms.

Goals: If I want to know whether something has been ported back I first 
do a quick check whether the revision is in the mergeinfo. If it is in 
there I usually trust it. If not I start checking some committed lines 
for presence in the branch. I currently mostly do this by hand.

I now learned, motivated by your question, that there is also a

     svn mergeinfo

command, that tells us, which commits have not yet been ported back. Now 
since we often do not maintain the mergeinfo property, the generated 
list is much to long (e.g. it would contain the commit numbers for the 
docs transform updates).

Example (assuming directory layout similar to the one in svn):

$ svn mergeinfo trunk/modules/ssl branches/2.4.x/modules/ssl

Not too many recent ones.

Where is mergeinfo and how is it maintained: It is a subversion property 
automatically maintained by subversion itself. So being inside 
branches/2.4.x you can call

$ svn propget svn:mergeinfo

When is it updated: subversion updates it when you use "svn merge" to 
backport a commit.

Example: Sitting in branches/2.4.x and wanting to backport r1234567 and 
r1234578 you would do:

svn merge -c r1234567 ../../trunk
svn merge -c r1234578 ../../trunk

(or use the trunk svn URL if your layout is different)

Subversion will then merge the commits, asking you to resolve any 
conflicts it encounters (likely e.g. the CHANGES file or the log tags file).

Once you commit the result, the numbers 1234567 and 1234578 are now part 
of the mergeinfo.


Always merge into a clean branch checkout and commit the whole branch. 
If you start to only commit parts of the branch after merging, svn will 
produce additional mergeinfo properties attached to sub directories or 
files. We don't want that.

Finally: you can directly edit the mergeinfo property using "svn 
propedit", but as usual this is not recommended.

Hope that helps, even it is wasn't really short.



View raw message