[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[BUG] Borked 1.5.x CHANGES merging

From: Eric Gillespie <epg_at_pretzelnet.org>
Date: Fri, 11 Apr 2008 20:55:54 -0700

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-298!
 84,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
Received on 2008-04-12 05:56:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.