Can you add svnversion of your wc before you run "svn merge", and the
revision/tag of the svn you're running?
--dave
On Fri, Apr 11, 2008 at 8:55 PM, Eric Gillespie <epg_at_pretzelnet.org> wrote:
> As I've merged changes to the 1.5.x branch I've noticed CHANGES's
> mergeinfo is always changing. I never understood this, but
> apparently it's from Hyrum (r30329) and I (r30003) (and maybe
> others) merging just CHANGES. I tried again tonight, and this is
> my story.
>
> Start with no tmp files, of course:
>
> 0 1.5.x% ls -lt .svn/tmp/*(.) | sed q
> zsh: no matches found: .svn/tmp/*(.)
>
> Let's run my merge, interrupting during the last section:
>
> 0 1.5.x% strace -o svnmergelog.interrupt =svn merge --accept theirs-full http://svn.collab.net/repos/svn/trunk/CHANGES CHANGES
> --- Merging r29081 through r29084 into 'CHANGES':
> U CHANGES
> --- Merging r29885 through r29894 into 'CHANGES':
> G CHANGES
> --- Merging r29901 through r29913 into 'CHANGES':
> G CHANGES
> --- Merging r29931 through r29938 into 'CHANGES':
> G CHANGES
> svn: Caught signal
>
> Mmmm, tmp files:
>
> 0 1.5.x% ls -lt .svn/tmp/*(.) | wc -l
> 242
> 0 1.5.x% ls -lt .svn/tmp/*(.) | sed q
> -rw-r----- 1 epg epg 138451 Apr 11 20:10 .svn/tmp/tempfile.242.tmp
>
> What the heck's in them?
>
> 0 1.5.x% sed 10q .svn/tmp/tempfile.242.tmp
> Version 1.5.0
> (?? ??? 2008, from /branches/1.5.x)
> http://svn.collab.net/repos/svn/tags/1.5.0
>
> User-visible changes:
> - Major new features:
> * Merge Tracking [foundational] (issue #820)
> * Sparse checkouts (see new '--depth' option) (issue #695)
> * Interactive conflict resolution (r25670 et al)
> * svn:externals handles relative URLs (issue #1336) and peg URLs
>
> Uh-oh; are they all copies of CHANGES?
>
> 0 1.5.x% for i in .svn/tmp/*(.); do grep -qs '^Version 1\.4' $i || echo $i; done
>
> Uh-huh.
>
> 0 1.5.x% time strace -o svnmergelog =svn merge --accept theirs-full http://svn.collab.net/repos/svn/trunk/CHANGES CHANGES
> --- Merging r29081 through r29084 into 'CHANGES':
> U CHANGES
> --- Merging r29885 through r29894 into 'CHANGES':
> G CHANGES
> --- Merging r29901 through r29913 into 'CHANGES':
> G CHANGES
> --- Merging r29931 through r29938 into 'CHANGES':
> G CHANGES
> strace -o svnmergelog =svn merge --accept theirs-full CHANGES 13.42s user 28.66s system 28% cpu 2:28.68 total
>
> I know this merge is much more complicated, but this does make
> for an interesting comparison:
>
> 0 1.5.x% time svn diff -r 29080:29938 http://svn.collab.net/repos/svn/trunk/CHANGES > /dev/null
> svn diff -r 29080:29938 http://svn.collab.net/repos/svn/trunk/CHANGES > 0.02s user 0.00s system 2% cpu 0.848 total
>
> Oh, and about those tmp files? Dig it:
>
> 0 1.5.x% nocorrect grep 'svn/tmp/tempfile.*EEXIST' svnmergelog | tail -2
> open(".svn/tmp/tempfile.1022.tmp", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
> open(".svn/tmp/tempfile.1023.tmp", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0666) = -1 EEXIST (File exists)
> 0 1.5.x% nocorrect grep -c 'svn/tmp/tempfile.*EEXIST' svnmergelog
> 338031
>
> Yikes, eh? We're not done yet:
>
> 0 1.5.x% nocorrect grep 'unlink.*svn/tmp/tempfile' svnmergelog | tail -2
> unlink(".svn/tmp/tempfile.1021.tmp.tmp") = -1 ENOENT (No such file or directory)
> unlink(".svn/tmp/tempfile.1023.tmp.tmp") = -1 ENOENT (No such file or directory)
>
> Where'd that extra .tmp suffix come from?
>
> Last but not least, note that the result of my merge isn't even correct:
>
> 1 1.5.x% svn di | diffstat
> CHANGES | 97 +++++++++++++++++++++++++++++++++-------------------------------
> 1 file changed, 51 insertions(+), 46 deletions(-)
> 0 1.5.x% svn diff http://svn.collab.net/repos/svn/{trunk,branches/1.5.x}/CHANGES
>
> Property changes on: CHANGES
> ___________________________________________________________________
> Added: svn:mergeinfo
> Merged /branches/1.5.x-r30215/CHANGES:r30236,30238,30245,30288
> Merged /branches/svn-mergeinfo-enhancements/CHANGES:r30122
> Merged /trunk/CHANGES:r29085-29089,29091,29094-29107,29111,29114,29117,29126-29127,29129-29133,29135-29150,29153-29164,29166-29170,29174,29176-29186,29188-29189,29193-29194,29198-29206,29208-29251,29254-29256,29261,29267-29273,29277,29280-29281,29284,29287-29303,29305-29307,29309-29343,29345-29348,29358-29379,29381-29392,29397,29399,29401,29409,29412,29414-29415,29417-29423,29425-29426,29429,29433-29434,29436-29447,29449-29466,29468-29478,29482,29484,29486-29487,29489,29491,29493,29496,29498,29508,29527-29528,29531,29533,29539-29540,29542,29544,29546,29551,29553,29556,29559,29565,29567-29569,29571-29578,29581,29583,29591,29594,29600,29603,29607,29611,29613-29614,29619,29623,29625-29626,29630-29631,29633-29634,29642,29645,29648,29650,29656,29659-29660,29663-29666,29671-29672,29677-29680,29692,29738-29739,29741-29744,29746,29751,29763,29767,29769-29770,29784,29786-29787,29797,29801,29815,29821,29824,29828,29835,29852,29854-29855,29857-29859,29868-29869,29876,29878,29883-29884,29895,29898,29900,29914,29920
,29922,29925,29930,29939-29940,29942,29950,29958,29962,29965,29967-29968,29980,29986,29994-29997,30004,30009,30020,30030,30050,30053-30054,30059,30061-30062,30067,30070,30074,30086,30098,30101,30112,30117,30124,30129-30130,30137,30145,30151,30159,30161-30162,30180-30181,30185,30210,30233,30237,30239,30246,30249,30256,30278-30279,30281,30285,30297,30299,30304,30319-30321,30328,30335-30336,30340,30342,30347,30362,30368,30373,30375,30378,30380,30392,30402,30407-30409,30412,30426,30428,30431,30439-30444,30448-30449,30453,30455,30460,30462-30464,30466-30467,30469-30474,30480,30482,30487,30489,30510,30516-30518,30520-30521,30523,30546,30548,30551-30552
>
> The text of CHANGES on branch and trunk are identical before my
> merge, yet not afterwards. WTF?
>
> So, bugs:
>
> - We have the world's dumbest tmpfile algorithm. Why the heck
> are we not using mkstemp?
> - Even though we catch SIGINT for cleanup, we don't clean these
> tmp files when merge is interrupted.
> - We sometimes append extra .tmp to a tmpfile before trying to
> remove it, thus failing; this is probably the same as previous.
> - The merge takes *FOREVER*.
> - Probabably because it appears to be fetching at lesat dozens of
> copies of the CHANGES file, I guess at various different revisions.
> - The final merge result isn't even correct.
>
> As a final insult, Perforce handles this case (cherrypick all
> kinds of revisions into your release branch and later sync one
> file fully with the main line) beautifully. Well, OK, the UI is
> awful, so maybe not "beautifully", but it works.
>
> Find the strace log at http://pretzelnet.org/tmp/svnmergelog.bz2
> (6 MB, 78 MB uncompressed).
>
> --
> Eric Gillespie <*> epg_at_pretzelnet.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-12 08:15:13 CEST