Thanks egoots, Andy, Erik, Ryan. Here are some preliminary results:
1.3.0: svnadmin dump oldrepo > oldrepo.dump
1.4.3: svnadmin create /svnrepos/newrepo
1.4.3: chown -R apache.apache !$
1.4.3: svnadmin load --force-uid /svnrepos/newrepo (as root)
oldrepo: 370 MB
newrepo: 273 MB (all FSFS)
Somewhat insidious in that some of the ownerships were preserved,
but not all, plus none of the modes: (I don't know what current
is used for, but obviously apache would not be able to write to it
from an svnadmin load.)
oldrepo:
total 220
drwxrwsr-x 5 apache apache 4096 Jun 29 01:16 .
drwxrwsr-x 7 apache apache 4096 Nov 3 2006 ..
-rw-rw-r-- 1 apache apache 13 Jun 29 01:16 current
-r--rw-r-- 1 apache apache 2 Nov 3 2006 format
-rw-rw-r-- 1 apache apache 5 Nov 3 2006 fs-type
drwxrwsr-x 2 apache apache 94208 Jun 29 01:16 revprops
drwxrwsr-x 2 apache apache 94208 Jun 29 01:16 revs
drwxrwsr-x 2 apache apache 4096 Jun 29 01:16 transactions
-rw-rw-r-- 1 apache apache 37 Nov 3 2006 uuid
-rw-rw-r-- 1 apache apache 0 Nov 3 2006 write-lock
newrepo:
drwxr-sr-x 5 apache apache 4096 Jun 29 13:04 .
drwxr-sr-x 7 apache apache 4096 Jun 29 12:41 ..
-rw-r--r-- 1 root apache 13 Jun 29 13:04 current
-r--r--r-- 1 apache apache 2 Jun 29 12:41 format
-rw-r--r-- 1 apache apache 5 Jun 29 12:41 fs-type
drwxr-sr-x 2 apache apache 135168 Jun 29 13:04 revprops
drwxr-sr-x 2 apache apache 135168 Jun 29 13:04 revs
drwxr-sr-x 2 apache apache 4096 Jun 29 13:04 transactions
-rw-r--r-- 1 root apache 37 Jun 29 12:41 uuid
-rw-r--r-- 1 apache apache 0 Jun 29 12:41 write-lock
Anne M. Hammond - Systems / Network Administration - Tech-X Corp
hammond_at_txcorp.com 720-974-1840
On Fri, 29 Jun 2007, Ryan Schmidt wrote:
>
> On Jun 29, 2007, at 06:04, Erik Huelsmann wrote:
>
>> On 6/29/07, Andy Levy wrote:
>>
>>> On 6/29/07, egoots wrote:
>>>
>>>> Anne M. Hammond wrote:
>>>>
>>>> > We currently use subversion 1.3.0 under apache https.
>>>> >
>>>> > I want to migrate to new hardware using subversion 1.4.3/.
>>>> >
>>>> > Is it possible to
>>>> > svnadmin dump
>>>> > svnadmin restore (on the new hardware)
>>>> > cp auth and access file from old server to new hardware
>>>> > then bring up the new hardware using the old hostname and IP address
>>>> > and the users will never know the difference?
>>>> >
>>>> > Or will users have to perform an entirely new checkout of
>>>> > the repos from the new hardware?
>>>>
>>>> The users will also have to upgrade to 1.4.x clients if you upgrade the
>>>> repository to 1.4.x
>>>
>>> I think that's only true if you're using file:/// access. Given that
>>> Anne is talking about auth and access files, it's safe to assume that
>>> she's not (as those don't apply to file:///).
>>>
>>>> Besides that, I "think" it should work out of the box.
>>>> At worst, you would have to do an svn switch --relocate
>>>
>>> If users have any locks on files, I don't think those are included in
>>> the dumpfile.
>>>
>>> There isn't (that I recall) an svnadmin "restore" - you need to do an
>>> svnadmin create to create the new repository, then svnadmin load to
>>> put everything in. This will change the UUID of the repository unless
>>> you use --force-uuid, so users will need to do an svn switch
>>> --relocate to pick up the new UUID (I think).
>>
>> If the server comes up with the same URLs for the repository, you
>> don't need to relocate. You can't update the UUID in the working copy,
>> since that's used to uniquely identify the repository. Thus, you
>> *have* to use --force-uuid when svnadmin loading it.
>
> That's not what "svnadmin help load" says. It says it will use the UUID in
> the dump automatically, assuming the repository was just created and is
> empty. And if the repository you're loading into is not empty, then forcing
> the UUID would seem to cause a disaster, since the repository the old working
> copies expect to find is not the one they're going to find (revision numbers
> will have changed, etc.).
>
> $ svnadmin help load
> load: usage: svnadmin load REPOS_PATH
>
> Read a 'dumpfile'-formatted stream from stdin, committing
> new revisions into the repository's filesystem. If the repository
> was previously empty, its UUID will, by default, be changed to the
> one specified in the stream. Progress feedback is sent to stdout.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 29 23:21:40 2007