Hello,
I setup a development infrastructure for an IC-design group
which has been having its trees under SVN for some time now.
Although the data set is getting big and complex (lots of exotic
tools involved in the build process, repos that sum to about
100GB), they never came across any serious problem with this
great tool.
Recently, however, restructuring build trees, they replaced some
externals by symlinks; bang: they could not update and merge
anymore.
Short description / as I understand things:
If one tries to update a working copy to a rev that would
replace an external by a symlink (or a file, I guess), update
fails because of the external tree conflicting with the new
symlink (which is normal). The problem is that
*the revision of the directory is being updated*,
although
*its external def (svn:externals prop.) is not being removed*
from the working copy (so further updates cannot fix that).
Googling a bit, it looked like this problem is a special case of
a very old one:
http://subversion.tigris.org/issues/show_bug.cgi?id=1672
Ours is only more likely to get detected, as the persistence of
the property *is the source* of the conflict.
Though the workaround (update back in rev, remove conflicting
external tree, update again) looks quite trivial in test cases,
things are, of course, often different in real life situations...
Notes:
- doing an intermediate commit between the removal of the
external ref and the creation of the symlink only helps if the
wc is first updated to this intermediate rev (quite logically)
- even if you do remove the external tree in the wc before
trying to update (result will then be as expected) svn
behavior still looks a bit weird as it:
- creates the symlink
- updates the dir (removing the property)
- tries to refetch the "external item" over the symlink
anyway! (which fails, fortunately):
+ svn up wc2
A wc2/b/a
U wc2/b
Fetching external item into 'wc2/b/a'
svn: 'wc2/b/a' already exists and is not a directory
--> wc2 is clean!
Option --ignore-externals can be used to hide this glitch
Going from 1.3 to 1.4.5 (on the server and/or on the client side)
did not change anything to this respect.
Anyone knows what happened to the bug entry above?
Anything I missed? (including a reference document stating
that such kind of things should be avoided at any costs if
using SVN?)
[Though the bug report above includes a bug reproduction script
that triggers the problem, I also made one to do some tests
with this particular case, so I included it below.]
Regards,
Stephane
case reproduction script:
----------------------------->8
#!/bin/ksh -x
tdir=/tmp/svntst
: "### create sandbox"
# rm -rf $tdir
mkdir $tdir && cd $tdir || exit 1
svnadmin create repo
: "### killer project will have dirs a and b"
svn co file://$tdir/repo wc0
mkdir wc0/a wc0/b
touch wc0/a/foo
svn add wc0/*
svn ci -m "created a and b" wc0
: "### create an external in b pointing to a"
svn ps svn:externals "a file://$tdir/repo/a" wc0/b
ls -l wc0/b
svn up wc0
ls -l wc0/b
svn ci -m "added external a in b" wc0
: "### other users start working at this rev"
svn co file://$tdir/repo wc1
svn co file://$tdir/repo wc2
: "### day 2: decided to replace external by symlink"
svn pd svn:externals wc0/b
# svn ci -m "removed external prop" wc0
rm -rf wc0/b/a
ln -s ../a wc0/b
svn add wc0/b/a
svn ci -m "replaced external by symlink to ../a" wc0
svn up wc0
ls -l wc0/b
: "### candid user of wc1 wants to update"
svn up wc1
rm -rf wc1/b/a
svn up wc1
ls -l wc1/b
: "### bug: dir rev was updated but external is still there"
rev=$(svn info wc1/b|awk '/^Rev/ {print $2}')
svn pg svn:externals -r$rev file://$tdir/repo/b
svn pg svn:externals wc1/b
: "### fixing requires going back"
svn up -r2 wc1
rm -rf wc1/b/a
svn up wc1
svn pg svn:externals wc1/b
: "### user of wc2 knows about the problem"
rm -rf wc2/b/a
svn up wc2
ls -l wc2/b
svn pg svn:externals wc2/b
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-07 22:25:56 CET