----- Original Message ----
> From: BRM <bm_witness_at_yahoo.com>
> To: Ryan Schmidt <subversion-2010b_at_ryandesign.com>
> ----- Original Message ----
> > On Sep 2, 2010, at 11:27, BRM wrote:
> > If you can afford to have the repository offline, make a dumpfile, twiddle
>it, load it
> > into a new repository, and have everybody check out new working copies, you
>may
> > want to consider doing that. The twiddling step would be done with the
>svndumptool
> > script. The advantage would be that you could correct the externals
>definitions in all
> > past revisions of the repository too, not just the HEAD, so that anybody
>needing to
> > check out a past revision would still have working externals in the
>repository's new
> > location. And do use relative externals this time so you won't have to do
>this kind
> > of surgery ever again, noting that the relative externals syntax is only
>compatible
> > with Subversion 1.5 and higher.
> That's a good thought. I might try doing that tonight. I'm aware of they
>syntax
>
> compat issue, and have no problem
> saying that we have to use 1.5 or higher; it's just a matter of getting the
> update through.
Okay - well, I decided to try this route, but was advised to try it on a test
repository first.
Good thing - as there is a bit of an issue, and one I need to avoid if I can...
The issue is that an existing working copy's externals are not being updated
when 'svn update' runs,
even though the externals have changed on the server through the update.
Here's my test:
1. Create a file-based repository:
$ cd /
$ mkdir svnTest && cd svnTest
$ svnadmin create Example1
$ mkdir -p ~/testsvn && cd ~/testsvn
$ export SVNROOT=/svnTest
$ svn co ${SVNROOT}/Example1 example1.wc
$ cd example1.wc
$ mkdir sub1 sub2
$ svn add sub1 sub2
$ svn commit -m "Adding some structure for test"
$ touch sub1/file1
$ svn add sub1/file1
$ svn commit -m "Adding a file for test"
$ svn pedit svn:externals sub2
set the svn:externals to:
sub2a file:///svnTest/Example1
save and quit
$ svn update
$ svn commit -m "Adding an external for test"
2. Make a backup of the working copy
$ cd ~/testsvn
$ tar -jcvvf example1.wc.tar.bz2 example1.wc
3. Dump the repository
$ cd /svnTest
$ svnadmin dump Example1 > Example1.dump
4. Switch the external reference from Example1 to Example2
$ cat Example1.dump | sed
's/file:\/\/\/svnTest\/Example1/file:\/\/\/svnTest\/Example2/' >
Example1-edited.dump
5. Load the edited dump into a new repository (Example2)
$ cd /svnTest
$ svnadmin create Example2
$ svnadmin load Example2 < Example1-edited.dump
6. Rename the Example1 repository so it looks like it was removed
$ cd /svnTest
$ mv Example1 Example1.removed
7. Relocate the Example1 working copy, then update it
$ cd ~/testsvn
$ cd example1.wc
$ svn switch --relocate file:///svnTest/Example1 file:///svnTest/Example2
$ svn update
At this point 'svn update' fails outright complaining that it cannot find
file:///svnTest/Example1 (since it was removed).
So I can live with sub2a not getting updated without an svn switch --relocate
occurring on it - integrity and all; however, I would have expected that
svn update the svn:externals on sub2. I could even live with having to rename
an existing external (sub2a -> sub2a.orig) and updating (it's kinda of
acceptable, but not ideal).
At this point, I would expect that the svn:externals property for 'sub2' match
what is in the Example2 repository.
However, an 'svn pget svn:externals sub2' reveals that it did not get updated.
I even tried 'svn update --force'.
I kind of expected that 'svn update --ignore-externals' would not update it
either - which is what I found when I tried it.
Now I tried this with a 1.5.1 and 1.6.6 versions of the svn toolchain; though if
it is working in something newer okay. However, I'm kind of stuck with those two
versions - ubuntu hardy-backports provides 1.5.1 and lucid uses 1.6.6.
Now why is this a "big issue" for me? B/c I and a number of my team members
have a lot of projects with svn:externals, and we need to update our working
copies.
I need to make this as seamless as possible. Scripting the svn switch
--relocate command is easy; but I shouldn't have to also edit the svn:externals
on each project
since that was already changed in the repository.
Now I may be able to alleviate my issue some through temporarily restoring an
alternate port that gets redirected to the server via proxy[1] (the old server
ran on example.com:82 and the new one is on example.com); but forcing people to
have to completely delete their working copies is not an easy option -
especially since there may be some changes in the working copies that have not
yet made it to the server.
Or am I missing some? At this point, I am not going to touch my primary
repository until I know the right solution - but that also means we're stuck.
TIA,
Ben
[1]http://silmor.de/49
Received on 2010-09-03 01:52:25 CEST