Re: svnmerge.py (Was: Re: mergeinfo ignorance)
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: mergeinfo ignorance
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
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
Re: svnmerge.py (Was: Re: mergeinfo ignorance)
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" 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)
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)
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
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
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
> 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
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: 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,120,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,130,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
mergeinfo ignorance
On Sun, Jul 22, 2012 at 9:48 AM, 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!
