You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2012/07/22 16:14:47 UTC

mergeinfo ignorance

On Sun, Jul 22, 2012 at 9:48 AM,  <rj...@apache.org> wrote:
> Author: rjung
> Date: Sun Jul 22 13:48:30 2012
> New Revision: 1364302
>
> URL: http://svn.apache.org/viewvc?rev=1364302&view=rev
> 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.

TIA!

Re: svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jim Jagielski wrote on Mon, Jul 23, 2012 at 11:55:32 -0400:
> Is this still useful: svnmerge.py ?
> 
> 	http://www.orcaware.com/svn/wiki/Svnmerge.py
> 

For 1.4 repositories (regardless of server software version) yes.  I'd
not use both svnmerge.py and 'svn merge' on the same branch, that's just
asking for trouble/headaches.

http://subversion.apache.org/docs/release-notes/1.5#compatibility

Re: svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Blair Zajac <bl...@orcaware.com>.
On 07/23/2012 08:55 AM, Jim Jagielski wrote:
> Is this still useful: svnmerge.py ?
>
> 	http://www.orcaware.com/svn/wiki/Svnmerge.py

It still gets occasional usage and people occasionally ask questions 
about it (such as today) but I recommend people switch to svn's builtin 
merge tracking if they are running svn 1.6 or later.

Blair

Re: svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jim Jagielski wrote on Mon, Jul 23, 2012 at 11:55:32 -0400:
> Is this still useful: svnmerge.py ?
> 
> 	http://www.orcaware.com/svn/wiki/Svnmerge.py
> 

For 1.4 repositories (regardless of server software version) yes.  I'd
not use both svnmerge.py and 'svn merge' on the same branch, that's just
asking for trouble/headaches.

http://subversion.apache.org/docs/release-notes/1.5#compatibility

Re: svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Rainer Jung <ra...@kippdata.de>.
On 23.07.2012 17:55, Jim Jagielski wrote:
> Is this still useful: svnmerge.py ?
>
> 	http://www.orcaware.com/svn/wiki/Svnmerge.py

A quick check of

http://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/svnmerge/

and the mailing list activity suggests, that there isn't much going on 
for the tools since about 2009.

There's a user post asking for differences to "svn merge" at

http://www.orcaware.com/pipermail/svnmerge/2011-May/002144.html

So it seems it only has limited use nowadays.

The tools seems to go back to very early svn days. svn merge isn't too 
bad IMHO. But YMMV.

Regards,

Rainer

Re: svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Greg Stein <gs...@gmail.com>.
Nah... obsoleted by merge tracking (svn:mergeinfo) with the svn 1.5 release.

Please ignore that script and use svn merge.

And also that svn is a TLP sibling nowadays can surely help :-)

Cheers,
-g
On Jul 23, 2012 10:56 AM, "Jim Jagielski" <ji...@jagunet.com> wrote:

> Is this still useful: svnmerge.py ?
>
>         http://www.orcaware.com/svn/wiki/Svnmerge.py
>
> On Jul 23, 2012, at 8:45 AM, Jim Jagielski wrote:
>
> > I for sure don't use 'svn merge' and am likely guilty (and the
> > orig post clearly indicates) of this... For awhile, svn merge
> > was as wonky as hell, so I simply skipped using it and instead
> > used the svn.merge script which, for the curious, does a simple
> > diff and patch.
> >
> > I'm guessing that things are better now ;)
> >
> > On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote:
> >
> >> On 22.07.2012 16:59, Eric Covener wrote:
> >>>> CAUTION:
> >>>>
> >>>> 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.
> >>>>
> >>>
> >>> I might be a culprit here, I use someones svn.merge script in a not so
> >>> clean checkout but then checkin individual files.  Will work on it.
> >>
> >> No culprit. At least in 2.4.x there is currently only one mergeinfo,
> all is fine :)
> >>
> >> Regards,
> >>
> >> Rainer
> >>
> >
>
>

Re: svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Rainer Jung <ra...@kippdata.de>.
On 23.07.2012 17:55, Jim Jagielski wrote:
> Is this still useful: svnmerge.py ?
>
> 	http://www.orcaware.com/svn/wiki/Svnmerge.py

A quick check of

http://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/svnmerge/

and the mailing list activity suggests, that there isn't much going on 
for the tools since about 2009.

There's a user post asking for differences to "svn merge" at

http://www.orcaware.com/pipermail/svnmerge/2011-May/002144.html

So it seems it only has limited use nowadays.

The tools seems to go back to very early svn days. svn merge isn't too 
bad IMHO. But YMMV.

Regards,

Rainer

svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Jim Jagielski <ji...@jaguNET.com>.
Is this still useful: svnmerge.py ?

	http://www.orcaware.com/svn/wiki/Svnmerge.py

On Jul 23, 2012, at 8:45 AM, Jim Jagielski wrote:

> I for sure don't use 'svn merge' and am likely guilty (and the
> orig post clearly indicates) of this... For awhile, svn merge
> was as wonky as hell, so I simply skipped using it and instead
> used the svn.merge script which, for the curious, does a simple
> diff and patch.
> 
> I'm guessing that things are better now ;)
> 
> On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote:
> 
>> On 22.07.2012 16:59, Eric Covener wrote:
>>>> CAUTION:
>>>> 
>>>> 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.
>>>> 
>>> 
>>> I might be a culprit here, I use someones svn.merge script in a not so
>>> clean checkout but then checkin individual files.  Will work on it.
>> 
>> No culprit. At least in 2.4.x there is currently only one mergeinfo, all is fine :)
>> 
>> Regards,
>> 
>> Rainer
>> 
>

Re: mergeinfo ignorance

Posted by Rainer Jung <ra...@kippdata.de>.
On 23.07.2012 19:21, Joe Orton wrote:
> On Mon, Jul 23, 2012 at 08:45:47AM -0400, Jim Jagielski wrote:
>> I for sure don't use 'svn merge' and am likely guilty (and the
>> orig post clearly indicates) of this... For awhile, svn merge
>> was as wonky as hell, so I simply skipped using it and instead
>> used the svn.merge script which, for the curious, does a simple
>> diff and patch.
>
> The one I use at http://people.apache.org/~jorton/svn.merge does use
> "svn merge" correctly (I hope!), possibly an older version didn't?

Nice.

You can nowadays shortcut

-r${prev}:${rev}

by

-c $rev

and no longer need the prev. That was an svn improvement I found very handy.

Regards,

Rainer

Re: mergeinfo ignorance

Posted by Joe Orton <jo...@redhat.com>.
On Mon, Jul 23, 2012 at 08:45:47AM -0400, Jim Jagielski wrote:
> I for sure don't use 'svn merge' and am likely guilty (and the
> orig post clearly indicates) of this... For awhile, svn merge
> was as wonky as hell, so I simply skipped using it and instead
> used the svn.merge script which, for the curious, does a simple
> diff and patch.

The one I use at http://people.apache.org/~jorton/svn.merge does use 
"svn merge" correctly (I hope!), possibly an older version didn't?

Regards, Joe

svnmerge.py (Was: Re: mergeinfo ignorance)

Posted by Jim Jagielski <ji...@jaguNET.com>.
Is this still useful: svnmerge.py ?

	http://www.orcaware.com/svn/wiki/Svnmerge.py

On Jul 23, 2012, at 8:45 AM, Jim Jagielski wrote:

> I for sure don't use 'svn merge' and am likely guilty (and the
> orig post clearly indicates) of this... For awhile, svn merge
> was as wonky as hell, so I simply skipped using it and instead
> used the svn.merge script which, for the curious, does a simple
> diff and patch.
> 
> I'm guessing that things are better now ;)
> 
> On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote:
> 
>> On 22.07.2012 16:59, Eric Covener wrote:
>>>> CAUTION:
>>>> 
>>>> 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.
>>>> 
>>> 
>>> I might be a culprit here, I use someones svn.merge script in a not so
>>> clean checkout but then checkin individual files.  Will work on it.
>> 
>> No culprit. At least in 2.4.x there is currently only one mergeinfo, all is fine :)
>> 
>> Regards,
>> 
>> Rainer
>> 
>

Re: mergeinfo ignorance

Posted by Jim Jagielski <ji...@jaguNET.com>.
I for sure don't use 'svn merge' and am likely guilty (and the
orig post clearly indicates) of this... For awhile, svn merge
was as wonky as hell, so I simply skipped using it and instead
used the svn.merge script which, for the curious, does a simple
diff and patch.

I'm guessing that things are better now ;)

On Jul 22, 2012, at 12:12 PM, Rainer Jung wrote:

> On 22.07.2012 16:59, Eric Covener wrote:
>>> CAUTION:
>>> 
>>> 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.
>>> 
>> 
>> I might be a culprit here, I use someones svn.merge script in a not so
>> clean checkout but then checkin individual files.  Will work on it.
> 
> No culprit. At least in 2.4.x there is currently only one mergeinfo, all is fine :)
> 
> Regards,
> 
> Rainer
>

Re: mergeinfo ignorance

Posted by Rainer Jung <ra...@kippdata.de>.
On 22.07.2012 16:59, Eric Covener wrote:
>> CAUTION:
>>
>> 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.
>>
>
> I might be a culprit here, I use someones svn.merge script in a not so
> clean checkout but then checkin individual files.  Will work on it.

No culprit. At least in 2.4.x there is currently only one mergeinfo, all 
is fine :)

Regards,

Rainer

Re: mergeinfo ignorance

Posted by Eric Covener <co...@gmail.com>.
> CAUTION:
>
> 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.
>

I might be a culprit here, I use someones svn.merge script in a not so
clean checkout but then checkin individual files.  Will work on it.

Re: mergeinfo ignorance

Posted by Rainer Jung <ra...@kippdata.de>.
On 22.07.2012 16:14, Jeff Trawick wrote:
> On Sun, Jul 22, 2012 at 9:48 AM,  <rj...@apache.org> wrote:
>> Author: rjung
>> Date: Sun Jul 22 13:48:30 2012
>> New Revision: 1364302
>>
>> URL: http://svn.apache.org/viewvc?rev=1364302&view=rev
>> 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
r1200482
r1203491
r1204968
r1206291
...
r1228816
r1242089
r1243246
r1294306
r1294471
r1328325
r1328326
r1358061

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
/httpd/httpd/branches/revert-ap-ldap:1150158-1150173
/httpd/httpd/branches/wombat-integration:723609-723841
/httpd/httpd/trunk:1200475,1200478,1200482,1200491,1200496,1200513,1200550,1200556,1200580,1200605,1200612,1200614,1200639,1200646,1200656,1200667,1200679,1200699,1200702,1200955,1200957,1200961,1200963,1200968,1201032,1201042,1201111,1201194,1201198,1201202,1201450,1201956,1202236,1202453,1202456,1202886,1203400,1203491,1203714,1203859,1203980,1204630,1204968,1204990,1205061,1205075,1205379,1205885,1206291,1206472,1206587,1206850,1206940,1206978,1207719,1208753,1208835,1209053,1209085,1209417,1209432,1209461,1209601,1209603,1209618,1209623,1209741,1209754,1209766,1209776,1209797-1209798,1209811-1209812,1209814,1209908,1209910,1209913,1209916-1209917,1209947,1209952,1210067,1210080,1210120,1210124,1210130,1210148,1210219,1210221,1210252,1210284,1210336,1210378,1210725,1210892,1210951,1210954,1211351-1211352,1211364,1211490,1211495,1211528,1211663,1211680,1212872,1212883,1213338,1213380-1213381,1213391,1213399,1213567,1214003,1214005,1214015,1215514,1220462,1220467,1220493,12!
 20524,12
20570,1220768,1220794,1220826,1220846,1221205,1221292,1222335,1222370,1222473,1222915,1222917,1222921,1222930,1223048,1225060,1225197-1225199,1225223,1225380,1225476,1225478,1225791,1225795-1225796,1226339,1226375,1227910,1228700,1228816,1229024,1229059,1229099,1229116,1229134,1229136,1229930,1230286,1231442,1231446,1231508,1231510,1231518,1232575,1232594,1232630,1232838,1234180,1234297,1234479,1234511,1234565,1234574,1234642-1234643,1234876,1234899,1235019,1236122,1236701,1237407,1238545,1238768,1239029-1239030,1239071,1239565,1240315,1240470,1240778,1241069,1241071,1242089,1242967,1243176,1243246,1243797,1243799,1244211,1245717,1290823,1290835,1291819-1291820,1291834,1291840,1292043,1293405,1293534-1293535,1293658,1293678,1293708,1294306,1294372,1294471,1297560,1299786,1300766,1301111,1301725,1302444,1302483,1302653,1302665,1302674,1303201,1303435,1303827,1304087,1304874-1304875,1307790,1308327,1308459,1309536,1325218,1325227,1325250,1325265,1325275,1325632,1326980,1326984!
 ,1326991,
1328325-1328326,1328339,1328345,1328950,1331115,1331942,1331977,1333969,1343085,1343087,1343935,1346905,1348036,1349905,1351015,1351071-1351072,1351074,1352911-1352912,1358061,1359057,1359881,1361784,1361791,1362020,1362538,1362707,1363589,1363829,1363832,1363836-1363837,1363853

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.

CAUTION:

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.

Regards,

Rainer