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

children of added dirs get "replaced" during merge in 1.6.x

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 20 Jan 2010 14:21:19 +0100

I'm trying to hunt down a strange issue where children in directories
added during a merge (i.e. copied from another branch) get committed
as "replaced" rather than "added".

This happens with a 1.6.x client (server version doesn't matter)
and only over http:// (both neon and serf).

It's not a presentation-level issue, the committed revision actually
has a "replace" action in the FSFS revision file.

It is fixed in trunk, but I'd like to get a fix for 1.6.x.
This is a really annoying bug because the replacements will spread
to other branches and cause all kinds of merging headaches later.

Any clues? See recipe below.

Thanks,
Stefan

$ R=http://localhost:8080/repos
$ svn co $R/trunk
A trunk/gamma/delta
A trunk/alpha
A trunk/epsilon
A trunk/epsilon/zeta
A trunk/beta
Checked out revision 2.
$ svn co $R/branch
A branch/gamma
A branch/gamma/delta
A branch/alpha
A branch/epsilon
A branch/epsilon/zeta
A branch/beta
Checked out revision 2.
$ cd branch/
$ svn mkdir foo
A foo
$ cd foo
$ echo a > a
$ svn add a
A a
$ cd ..
$ svn ci -mm
Adding foo
Adding foo/a
Transmitting file data ..
Committed revision 3.
$ cd ../trunk/
$ svn up
 At revision 3.
$ svn merge ^/trunk ^/branch # merge --reintegrate ^/branch has same problem
--- Merging differences between repository URLs into '.':
A foo
A foo/a
svn$ svn st
 M .
A + foo
A + foo/a
$ svn ci -mm
Sending .
Adding foo
Adding foo/a
Committed revision 4.
$ svn log -r4 -v ^/
------------------------------------------------------------------------
r4 | (no author) | 2010-01-20 13:38:37 +0100 (Wed, 20 Jan 2010) | 1 line
Changed paths:
   M /trunk
   A /trunk/foo (from /branch/foo:3)
   R /trunk/foo/a (from /branch/foo/a:3)
Received on 2010-01-20 14:21:59 CET

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.