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
Received on Fri Jun 29 22:39:10 2007