You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Anne M. Hammond" <ha...@txcorp.com> on 2007/06/29 04:53:01 UTC
migrate to new server - subversion 1.3.0 -> 1.4.3
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?
TIA < Anne
Anne M. Hammond - Systems / Network Administration - Tech-X Corp
hammond_at_txcorp.com 720-974-1840
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: migrate to new server - subversion 1.3.0 -> 1.4.3
Posted by Thomas Harold <tg...@tgharold.com>.
Anne M. Hammond wrote:
> 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
That result doesn't surprise me too much... I would guess that the
parent directory is not set to 770 and that you ran the restore command
as root. It looks like the repository was originally setup with a chmod
value of 700. You may also be seeing (minor) issues in the db/revs
folder. I'm betting they're all owned by root and that Apache can't
write to existing revs files. In FSVS, this probably won't cause an
issue, except maybe you can't change older log messages.
Assuming your repositories are stored under /var/svn, I believe the
following would fix it:
# cd /var/svn
# chmod -R 770 newrepos
# chmod -R g+s newrepos/db
# chown -R apache:apache newrepos
The last step is mostly optional, because as long as the repository
folder is set as g+rw (a chmod of x7x), Apache won't care who currently
owns the "current" file.
...
Another thing that I do on all of our repositories is to create a new
unix group for each repository and use chgrp to make the repository
folder owned by that group. So for a repository named "newrepos", I'd
create a "svn-newrepos" group, add Apache's user account to the list of
members, then change group ownership on the repository folder.
Either:
# cd /var/svn
# chown -R apache:svn-newrepos newrepos
Or:
# cd /var/svn
# chgrp -R svn-newrepos newrepos
Probably overkill if Apache is your only access method, but required
(AFAIK) if you want to support multiple access methods (such as svn+ssh).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: migrate to new server - subversion 1.3.0 -> 1.4.3
Posted by "Anne M. Hammond" <ha...@txcorp.com>.
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
Re: migrate to new server - subversion 1.3.0 -> 1.4.3
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
Re: migrate to new server - subversion 1.3.0 -> 1.4.3
Posted by eg <eg...@gmail.com>.
Erik Huelsmann wrote:
> On 6/29/07, Andy Levy <an...@gmail.com> wrote:
>> > >
>> > > 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:///).
Right. I was also thinking about taking advantage of the new features...
but it sure doesn't read that way :(
If you want the clients to "to get the full benefits" of the new binary
delta encoding improvements added in 1.4, then both client and server
will need to be upgraded to 1.4. In this case, the remaining benefits
would be that your "network traffic becomes smaller and faster".
>>
>> > Besides that, I "think" it should work out of the box.
>> > At worst, you would have to do an svn switch --relocate
>>
What I meant to say was "even if you loaded the repository onto a new
server with a different URL(instead of the same one), then the worst the
users would need to do is an svn switch --relocate. Not a full checkout.
Yikes. Sorry for my badly worded reply here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: migrate to new server - subversion 1.3.0 -> 1.4.3
Posted by Erik Huelsmann <eh...@gmail.com>.
On 6/29/07, Andy Levy <an...@gmail.com> wrote:
> On 6/29/07, egoots <eg...@gmail.com> 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.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: migrate to new server - subversion 1.3.0 -> 1.4.3
Posted by Andy Levy <an...@gmail.com>.
On 6/29/07, egoots <eg...@gmail.com> 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).
Don't forget to copy your hook scripts too!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: migrate to new server - subversion 1.3.0 -> 1.4.3
Posted by egoots <eg...@gmail.com>.
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
Besides that, I "think" it should work out of the box.
At worst, you would have to do an svn switch --relocate
see: http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.switch.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org