You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Giulio Troccoli <gi...@mediatelgroup.co.uk> on 2011/08/05 13:09:43 UTC
Estimation of repository upgrade
I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17.
We have 75 repositories, with an average size of 30MB. They're not big,
I agree, but I wonder if anyone has any tip on how to estimate how long
the "svnadmin upgrade" command will take. I mean, will it be a matter or
minutes or hours?
Also, I'm confused whether I need to run "svnadmin pack" as well, or if
the upgrade will do it for me. If I need to run, does anyone has an idea
of how long it could take?
Thanks
Giulio Troccoli
Re: Estimation of repository upgrade
Posted by Les Mikesell <le...@gmail.com>.
On 8/5/2011 12:33 PM, Bob Archer wrote:
>
>>> Until you manually copy over the $repodir/db/uuid file, this is true.
>>> That's one of the "relevant configuraton files" I referred to.
>> So, are you saying svnsync will be faster than a dump/load?
>>
>> I didn't know the guid was stored in a file.
>>
>> svnsync is slower than dump/load. I think the issue is that you can keep the
>> old repository online during the process and switch when you are ready.
>>
>> BTW, why copy a file you are not supposed to when you could just use the
>> svnadmin setuuid command to make the Repository UUID match between
>> the two repositories? No need to involve yourself in the internals of the
>> repository when there is a public interface to do it for you.
>
> Yes, that was my thought too. I will just run the dump/load during the weekend again. Also, now that I know you can dump/load in a single step rather than to disk then load it shouldn't be so bad.
Svnsync can be run anytime without bothering the working repo very much
so you can have most of the contents in the new one well ahead of time
and repeated runs pick up where it left off. You just need to make sure
that no commits are done while you make the final run before the cutover
- which can be very quick.
> I do think I will plan to dump filter out all the paths with binaries and move them to the file system only or a separate repository that can be purged periodically and then use externals to bring them into the WC. I think some people here have mentioned a binary library tool that rotates your binaries... or I can just add it to my nant scripts like I currently do it with test installers.
If you come up with a good scheme for this that doesn't interfere too
much with using externals to pull in component libraries without
recompiling, please post it.
--
Les Mikesell
lesmikesell@gmail.com
RE: Estimation of repository upgrade
Posted by Bob Archer <Bo...@amsi.com>.
> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bo...@amsi.com> wrote:
>
> > Until you manually copy over the $repodir/db/uuid file, this is true.
> > That's one of the "relevant configuraton files" I referred to.
> So, are you saying svnsync will be faster than a dump/load?
>
> I didn't know the guid was stored in a file.
>
> svnsync is slower than dump/load. I think the issue is that you can keep the
> old repository online during the process and switch when you are ready.
>
> BTW, why copy a file you are not supposed to when you could just use the
> svnadmin setuuid command to make the Repository UUID match between
> the two repositories? No need to involve yourself in the internals of the
> repository when there is a public interface to do it for you.
Yes, that was my thought too. I will just run the dump/load during the weekend again. Also, now that I know you can dump/load in a single step rather than to disk then load it shouldn't be so bad.
I do think I will plan to dump filter out all the paths with binaries and move them to the file system only or a separate repository that can be purged periodically and then use externals to bring them into the WC. I think some people here have mentioned a binary library tool that rotates your binaries... or I can just add it to my nant scripts like I currently do it with test installers.
Thanks,
BOb
Re: Estimation of repository upgrade
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Aug 5, 2011 at 2:12 PM, Bob Archer <Bo...@amsi.com> wrote:
> > On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann <eh...@gmail.com> wrote:
> >
> > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard <ma...@gmail.com>
> > wrote:
> > On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bo...@amsi.com> wrote:
> >
> > > Until you manually copy over the $repodir/db/uuid file, this is true.
> > > That's one of the "relevant configuraton files" I referred to.
> > So, are you saying svnsync will be faster than a dump/load?
> >
> > I didn't know the guid was stored in a file.
> >
> > svnsync is slower than dump/load. I think the issue is that you can keep
> the
> > old repository online during the process and switch when you are ready.
> >
> > But there's no difference in running 'checkout' repeatedly, svnsync or
> > svnadmin dump; all methods can be used concurrently and don't require
> > taking down the repository. Of course, running during the weekend may
> > help mitigate the performance effect it may have on users if you start
> > claiming large amounts of CPU from your server.
> >
> > Anytime the entire time it takes to dump/load a repository exceeds the
> > amount of time you can reasonably block writes to the old repository, it
> is
> > beneficial to be able to use svnsync. When using svnsync, it can take as
> long
> > as it needs to because you have total control over the switchover and can
> do
> > it with minimal downtime. But the actual time to do svnsync is generally
> > longer than dump/load. My point was only that you do not use svnsync
> > because it is faster, you do it because you can better control and
> minimize
> > the downtime.
>
> I'm never sure... should I dump with 1.6 binaries and then load with 1.7
> binaries. Or, upgrade the binaries and then dump and load with the most
> recent binaries? Or does it not matter since the dump file format is the
> same for all 1.x versions?
>
For the most part it does not matter for the reason you state. An exception
is for people using BDB. They should always dump using their current
binaries. If the new binaries do not have BDB support or include a newer
version of BDB they will not be able to dump the old repository. For FSFS
it does not matter since all new versions can read all old versions fine.
I think dump of fsfs might be a little faster in 1.7 due to some of the
caching changes. So it might make sense to try it with new binaries.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Estimation of repository upgrade
Posted by Bob Archer <Bo...@amsi.com>.
> On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann <eh...@gmail.com> wrote:
>
> On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard <ma...@gmail.com>
> wrote:
> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bo...@amsi.com> wrote:
>
> > Until you manually copy over the $repodir/db/uuid file, this is true.
> > That's one of the "relevant configuraton files" I referred to.
> So, are you saying svnsync will be faster than a dump/load?
>
> I didn't know the guid was stored in a file.
>
> svnsync is slower than dump/load. I think the issue is that you can keep the
> old repository online during the process and switch when you are ready.
>
> But there's no difference in running 'checkout' repeatedly, svnsync or
> svnadmin dump; all methods can be used concurrently and don't require
> taking down the repository. Of course, running during the weekend may
> help mitigate the performance effect it may have on users if you start
> claiming large amounts of CPU from your server.
>
> Anytime the entire time it takes to dump/load a repository exceeds the
> amount of time you can reasonably block writes to the old repository, it is
> beneficial to be able to use svnsync. When using svnsync, it can take as long
> as it needs to because you have total control over the switchover and can do
> it with minimal downtime. But the actual time to do svnsync is generally
> longer than dump/load. My point was only that you do not use svnsync
> because it is faster, you do it because you can better control and minimize
> the downtime.
I'm never sure... should I dump with 1.6 binaries and then load with 1.7 binaries. Or, upgrade the binaries and then dump and load with the most recent binaries? Or does it not matter since the dump file format is the same for all 1.x versions?
BOb
Re: Estimation of repository upgrade
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann <eh...@gmail.com> wrote:
>
> On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard <ma...@gmail.com> wrote:
>
>> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bo...@amsi.com> wrote:
>>
>>
>>> > Until you manually copy over the $repodir/db/uuid file, this is true.
>>> > That's one of the "relevant configuraton files" I referred to.
>>>
>>> So, are you saying svnsync will be faster than a dump/load?
>>>
>>> I didn't know the guid was stored in a file.
>>>
>>
>> svnsync is slower than dump/load. I think the issue is that you can keep
>> the old repository online during the process and switch when you are ready.
>>
>
> But there's no difference in running 'checkout' repeatedly, svnsync or
> svnadmin dump; all methods can be used concurrently and don't require taking
> down the repository. Of course, running during the weekend may help mitigate
> the performance effect it may have on users if you start claiming large
> amounts of CPU from your server.
>
Anytime the entire time it takes to dump/load a repository exceeds the
amount of time you can reasonably block writes to the old repository, it is
beneficial to be able to use svnsync. When using svnsync, it can take as
long as it needs to because you have total control over the switchover and
can do it with minimal downtime. But the actual time to do svnsync is
generally longer than dump/load. My point was only that you do not use
svnsync because it is faster, you do it because you can better control and
minimize the downtime.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Estimation of repository upgrade
Posted by Erik Huelsmann <eh...@gmail.com>.
On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bo...@amsi.com> wrote:
>
>
>> > Until you manually copy over the $repodir/db/uuid file, this is true.
>> > That's one of the "relevant configuraton files" I referred to.
>>
>> So, are you saying svnsync will be faster than a dump/load?
>>
>> I didn't know the guid was stored in a file.
>>
>
> svnsync is slower than dump/load. I think the issue is that you can keep
> the old repository online during the process and switch when you are ready.
>
But there's no difference in running 'checkout' repeatedly, svnsync or
svnadmin dump; all methods can be used concurrently and don't require taking
down the repository. Of course, running during the weekend may help mitigate
the performance effect it may have on users if you start claiming large
amounts of CPU from your server.
Bye,
Erik.
Re: Estimation of repository upgrade
Posted by Erik Huelsmann <eh...@gmail.com>.
On Fri, Aug 5, 2011 at 7:52 PM, Les Mikesell <le...@gmail.com> wrote:
> On 8/5/2011 12:27 PM, Mark Phippard wrote:
>
>>
>> > Until you manually copy over the $repodir/db/uuid file, this is
>> true.
>> > That's one of the "relevant configuraton files" I referred to.
>>
>> So, are you saying svnsync will be faster than a dump/load?
>>
>> I didn't know the guid was stored in a file.
>>
>>
>> svnsync is slower than dump/load. I think the issue is that you can
>> keep the old repository online during the process and switch when you
>> are ready.
>>
>> BTW, why copy a file you are not supposed to when you could just use the
>> svnadmin setuuid command to make the Repository UUID match between the
>> two repositories? No need to involve yourself in the internals of the
>> repository when there is a public interface to do it for you.
>>
>
> Can you copy from source to dest in one step with the interface (or
> svnsync) like scp or rsync will do for you?
You can use svnadmin hotcopy to do that, but it won't have the same effect
as reloading.
Bye,
Erik.
Re: Estimation of repository upgrade
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Aug 5, 2011 at 1:52 PM, Les Mikesell <le...@gmail.com> wrote:
> On 8/5/2011 12:27 PM, Mark Phippard wrote:
>
>>
>> > Until you manually copy over the $repodir/db/uuid file, this is
>> true.
>> > That's one of the "relevant configuraton files" I referred to.
>>
>> So, are you saying svnsync will be faster than a dump/load?
>>
>> I didn't know the guid was stored in a file.
>>
>>
>> svnsync is slower than dump/load. I think the issue is that you can
>> keep the old repository online during the process and switch when you
>> are ready.
>>
>> BTW, why copy a file you are not supposed to when you could just use the
>> svnadmin setuuid command to make the Repository UUID match between the
>> two repositories? No need to involve yourself in the internals of the
>> repository when there is a public interface to do it for you.
>>
>
> Can you copy from source to dest in one step with the interface (or
> svnsync) like scp or rsync will do for you?
>
Are you talking about the setuuid command?
$ svnadmin help setuuid
setuuid: usage: svnadmin setuuid REPOS_PATH [NEW_UUID]
Reset the repository UUID for the repository located at REPOS_PATH. If
NEW_UUID is provided, use that as the new repository UUID; otherwise,
generate a brand new UUID for the repository.
Script it however you choose.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Estimation of repository upgrade
Posted by Les Mikesell <le...@gmail.com>.
On 8/5/2011 12:27 PM, Mark Phippard wrote:
>
> > Until you manually copy over the $repodir/db/uuid file, this is true.
> > That's one of the "relevant configuraton files" I referred to.
>
> So, are you saying svnsync will be faster than a dump/load?
>
> I didn't know the guid was stored in a file.
>
>
> svnsync is slower than dump/load. I think the issue is that you can
> keep the old repository online during the process and switch when you
> are ready.
>
> BTW, why copy a file you are not supposed to when you could just use the
> svnadmin setuuid command to make the Repository UUID match between the
> two repositories? No need to involve yourself in the internals of the
> repository when there is a public interface to do it for you.
Can you copy from source to dest in one step with the interface (or
svnsync) like scp or rsync will do for you?
--
Les Mikesell
lesmikesell@gmail.com
Re: Estimation of repository upgrade
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Aug 5, 2011 at 1:27 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bo...@amsi.com> wrote:
>
>>
>> > Until you manually copy over the $repodir/db/uuid file, this is true.
>> > That's one of the "relevant configuraton files" I referred to.
>>
>> So, are you saying svnsync will be faster than a dump/load?
>>
>> I didn't know the guid was stored in a file.
>
> svnsync is slower than dump/load. I think the issue is that you can keep
> the old repository online during the process and switch when you are ready.
And you can start the process a week in advance, run performance tests
on the new server, provide read access to run performance and
regression tests, etc. It's often a much safer way to do a staged
migration.
> BTW, why copy a file you are not supposed to when you could just use the
> svnadmin setuuid command to make the Repository UUID match between the two
> repositories? No need to involve yourself in the internals of the
> repository when there is a public interface to do it for you.
Good point.
Re: Estimation of repository upgrade
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bo...@amsi.com> wrote:
> > Until you manually copy over the $repodir/db/uuid file, this is true.
> > That's one of the "relevant configuraton files" I referred to.
>
> So, are you saying svnsync will be faster than a dump/load?
>
> I didn't know the guid was stored in a file.
>
svnsync is slower than dump/load. I think the issue is that you can keep
the old repository online during the process and switch when you are ready.
BTW, why copy a file you are not supposed to when you could just use the
svnadmin setuuid command to make the Repository UUID match between the two
repositories? No need to involve yourself in the internals of the
repository when there is a public interface to do it for you.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Estimation of repository upgrade
Posted by Bob Archer <Bo...@amsi.com>.
> On Fri, Aug 5, 2011 at 12:19 PM, Bob Archer <Bo...@amsi.com> wrote:
> >> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer <Bo...@amsi.com>
> wrote:
> >>
> >> > Has anything been done to improve the speed of a load. Last time I
> >> > did it,
> >> when moving from 1.5 to 1.6 it took over 12 hours. And now, two years
> >> later the repo is probably quite a bit bigger (because we stupidly
> >> store binaries in it, I might change that when upgrading to 1.7).
> >>
> >> You can pre-configure by using svnsync to pre-create a new
> >> repository, and replicate relevant configuration files or scripts
> >> manually when ready to switchover. This is what I've used for
> >> migrating between servers that do not have shared back end storage,
> >> especially when updating operating systems and Subversion releases on
> the servers.
> >
> > But, doesn't that change the GUID of the repository thus not allowing a
> relocate switch?
>
> Until you manually copy over the $repodir/db/uuid file, this is true.
> That's one of the "relevant configuraton files" I referred to.
So, are you saying svnsync will be faster than a dump/load?
I didn't know the guid was stored in a file.
BOb
Re: Estimation of repository upgrade
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Aug 5, 2011 at 12:19 PM, Bob Archer <Bo...@amsi.com> wrote:
>> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer <Bo...@amsi.com> wrote:
>>
>> > Has anything been done to improve the speed of a load. Last time I did it,
>> when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later
>> the repo is probably quite a bit bigger (because we stupidly store binaries in
>> it, I might change that when upgrading to 1.7).
>>
>> You can pre-configure by using svnsync to pre-create a new repository, and
>> replicate relevant configuration files or scripts manually when ready to
>> switchover. This is what I've used for migrating between servers that do not
>> have shared back end storage, especially when updating operating systems
>> and Subversion releases on the servers.
>
> But, doesn't that change the GUID of the repository thus not allowing a relocate switch?
Until you manually copy over the $repodir/db/uuid file, this is true.
That's one of the "relevant configuraton files" I referred to.
RE: Estimation of repository upgrade
Posted by Bob Archer <Bo...@amsi.com>.
> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer <Bo...@amsi.com> wrote:
>
> > Has anything been done to improve the speed of a load. Last time I did it,
> when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later
> the repo is probably quite a bit bigger (because we stupidly store binaries in
> it, I might change that when upgrading to 1.7).
>
> You can pre-configure by using svnsync to pre-create a new repository, and
> replicate relevant configuration files or scripts manually when ready to
> switchover. This is what I've used for migrating between servers that do not
> have shared back end storage, especially when updating operating systems
> and Subversion releases on the servers.
But, doesn't that change the GUID of the repository thus not allowing a relocate switch?
BOb
Re: Estimation of repository upgrade
Posted by Giulio Troccoli <gi...@mediatelgroup.co.uk>.
On 05/08/11 17:11, Nico Kadel-Garcia wrote:
> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer<Bo...@amsi.com> wrote:
>
>> Has anything been done to improve the speed of a load. Last time I did it, when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later the repo is probably quite a bit bigger (because we stupidly store binaries in it, I might change that when upgrading to 1.7).
> You can pre-configure by using svnsync to pre-create a new repository,
> and replicate relevant configuration files or scripts manually when
> ready to switchover. This is what I've used for migrating between
> servers that do not have shared back end storage, especially when
> updating operating systems and Subversion releases on the servers.
Thanks Nico, I was thinking along those lines. However, the need for an
upgrade is mostly for bug fixes and the fact that 1.4 is out of support.
We will not use any (that I know of) of the new feature in 1.6 so I'm
not even sure now if we need to run an svnadmin upgrade a all.
Re: Estimation of repository upgrade
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer <Bo...@amsi.com> wrote:
> Has anything been done to improve the speed of a load. Last time I did it, when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later the repo is probably quite a bit bigger (because we stupidly store binaries in it, I might change that when upgrading to 1.7).
You can pre-configure by using svnsync to pre-create a new repository,
and replicate relevant configuration files or scripts manually when
ready to switchover. This is what I've used for migrating between
servers that do not have shared back end storage, especially when
updating operating systems and Subversion releases on the servers.
RE: Estimation of repository upgrade
Posted by Bob Archer <Bo...@amsi.com>.
> On Fri, Aug 5, 2011 at 10:11 AM, Giulio Troccoli
> <gi...@mediatelgroup.co.uk> wrote:
>
>
> On 05/08/11 14:18, Mark Phippard wrote:
>
> On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli
> <giulio.troccoli@mediatelgroup.co.uk
> <ma...@mediatelgroup.co.uk>> wrote:
>
> I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17.
>
> We have 75 repositories, with an average size of 30MB. They're not
> big, I agree, but I wonder if anyone has any tip on how to
> estimate how long the "svnadmin upgrade" command will take. I
> mean, will it be a matter or minutes or hours?
>
>
> svnadmin upgrade runs in literally a few milliseconds. All it does is change the
> format number of the repository. If you want to fully move to all of the new
> repository features in 1.6 you have to do dump/load which will take longer.
>
> Wouldn't svnadmin upgrade give me the exact same thing as a dump/load
> cycle? If not, what would be different?
>
> svnadmin upgrade bumps the repository format number which allows certain
> new features to be used. But there are other things like representation-
> sharing that require a full dump/load to get.
>
Has anything been done to improve the speed of a load. Last time I did it, when moving from 1.5 to 1.6 it took over 12 hours. And now, two years later the repo is probably quite a bit bigger (because we stupidly store binaries in it, I might change that when upgrading to 1.7).
BOb
Re: Estimation of repository upgrade
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Aug 5, 2011 at 10:11 AM, Giulio Troccoli <
giulio.troccoli@mediatelgroup.co.uk> wrote:
>
>
> On 05/08/11 14:18, Mark Phippard wrote:
>
> On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli <giulio.troccoli@**
>> mediatelgroup.co.uk <gi...@mediatelgroup.co.uk> <mailto:
>> giulio.troccoli@**mediatelgroup.co.uk<gi...@mediatelgroup.co.uk>>>
>> wrote:
>>
>> I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17.
>>
>> We have 75 repositories, with an average size of 30MB. They're not
>> big, I agree, but I wonder if anyone has any tip on how to
>> estimate how long the "svnadmin upgrade" command will take. I
>> mean, will it be a matter or minutes or hours?
>>
>>
>> svnadmin upgrade runs in literally a few milliseconds. All it does is
>> change the format number of the repository. If you want to fully move to
>> all of the new repository features in 1.6 you have to do dump/load which
>> will take longer.
>>
>
> Wouldn't svnadmin upgrade give me the exact same thing as a dump/load
> cycle? If not, what would be different?
svnadmin upgrade bumps the repository format number which allows certain new
features to be used. But there are other things like representation-sharing
that require a full dump/load to get.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Estimation of repository upgrade
Posted by Andy Levy <an...@gmail.com>.
On Fri, Aug 5, 2011 at 10:11, Giulio Troccoli
<gi...@mediatelgroup.co.uk> wrote:
>
>
> On 05/08/11 14:18, Mark Phippard wrote:
>>
>> On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli
>> <giulio.troccoli@mediatelgroup.co.uk
>> <ma...@mediatelgroup.co.uk>> wrote:
>>
>> I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17.
>>
>> We have 75 repositories, with an average size of 30MB. They're not
>> big, I agree, but I wonder if anyone has any tip on how to
>> estimate how long the "svnadmin upgrade" command will take. I
>> mean, will it be a matter or minutes or hours?
>>
>>
>> svnadmin upgrade runs in literally a few milliseconds. All it does is
>> change the format number of the repository. If you want to fully move to
>> all of the new repository features in 1.6 you have to do dump/load which
>> will take longer.
>
> Wouldn't svnadmin upgrade give me the exact same thing as a dump/load cycle?
> If not, what would be different?
svnadmin upgrade upgrades the repository in-place to let you use the
newer features going forward, but they won't be available on older
revisions.
Re: Estimation of repository upgrade
Posted by Giulio Troccoli <gi...@mediatelgroup.co.uk>.
On 05/08/11 14:18, Mark Phippard wrote:
> On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli
> <giulio.troccoli@mediatelgroup.co.uk
> <ma...@mediatelgroup.co.uk>> wrote:
>
> I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17.
>
> We have 75 repositories, with an average size of 30MB. They're not
> big, I agree, but I wonder if anyone has any tip on how to
> estimate how long the "svnadmin upgrade" command will take. I
> mean, will it be a matter or minutes or hours?
>
>
> svnadmin upgrade runs in literally a few milliseconds. All it does is
> change the format number of the repository. If you want to fully move
> to all of the new repository features in 1.6 you have to do dump/load
> which will take longer.
Wouldn't svnadmin upgrade give me the exact same thing as a dump/load
cycle? If not, what would be different?
>
> Also, I'm confused whether I need to run "svnadmin pack" as well,
> or if the upgrade will do it for me. If I need to run, does anyone
> has an idea of how long it could take?
>
>
> svnadmin pack is never an automatic feature. Unless you are really
> short on inodes in the volume I would not even recommend running it.
>
Thanks
Giulio Trocccoli
Re: Estimation of repository upgrade
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli <
giulio.troccoli@mediatelgroup.co.uk> wrote:
> I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17.
>
> We have 75 repositories, with an average size of 30MB. They're not big, I
> agree, but I wonder if anyone has any tip on how to estimate how long the
> "svnadmin upgrade" command will take. I mean, will it be a matter or minutes
> or hours?
>
svnadmin upgrade runs in literally a few milliseconds. All it does is
change the format number of the repository. If you want to fully move to
all of the new repository features in 1.6 you have to do dump/load which
will take longer.
>
> Also, I'm confused whether I need to run "svnadmin pack" as well, or if the
> upgrade will do it for me. If I need to run, does anyone has an idea of how
> long it could take?
>
svnadmin pack is never an automatic feature. Unless you are really short on
inodes in the volume I would not even recommend running it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Estimation of repository upgrade
Posted by Andy Levy <an...@gmail.com>.
On Fri, Aug 5, 2011 at 07:09, Giulio Troccoli
<gi...@mediatelgroup.co.uk> wrote:
> I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17.
>
> We have 75 repositories, with an average size of 30MB. They're not big, I
> agree, but I wonder if anyone has any tip on how to estimate how long the
> "svnadmin upgrade" command will take. I mean, will it be a matter or minutes
> or hours?
>
> Also, I'm confused whether I need to run "svnadmin pack" as well, or if the
> upgrade will do it for me. If I need to run, does anyone has an idea of how
> long it could take?
I don't believe the upgrade automatically packs the revisions. How
long either of these operations will take depends greatly upon the
repository content and your hardware.
Make a copy of one (or more) of the repositories, and test it for
yourself on another system to get an idea of the time required.