Re: Estimation of repository upgrade

2011-08-05 Thread Mark Phippard
On Fri, Aug 5, 2011 at 2:12 PM, Bob Archer wrote: > > On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann wrote: > > > > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard > > wrote: > > On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: > > > > > Until you manually copy over the $repodir/db/uuid file, t

RE: Estimation of repository upgrade

2011-08-05 Thread Bob Archer
> On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann wrote: > > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard > wrote: > On Fri, Aug 5, 2011 at 1:19 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"

Re: Estimation of repository upgrade

2011-08-05 Thread Mark Phippard
On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann wrote: > > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard wrote: > >> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer wrote: >> >> >>> > Until you manually copy over the $repodir/db/uuid file, this is true. >>> > That's one of the "relevant configuraton

Re: Estimation of repository upgrade

2011-08-05 Thread Les Mikesell
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 slo

Re: Estimation of repository upgrade

2011-08-05 Thread Mark Phippard
On Fri, Aug 5, 2011 at 1:52 PM, Les Mikesell 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

Re: Estimation of repository upgrade

2011-08-05 Thread Erik Huelsmann
On Fri, Aug 5, 2011 at 7:52 PM, Les Mikesell 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

Re: Estimation of repository upgrade

2011-08-05 Thread Les Mikesell
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

Re: Estimation of repository upgrade

2011-08-05 Thread Erik Huelsmann
On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard wrote: > On Fri, Aug 5, 2011 at 1:19 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 fas

Re: Estimation of repository upgrade

2011-08-05 Thread Nico Kadel-Garcia
On Fri, Aug 5, 2011 at 1:27 PM, Mark Phippard wrote: > On Fri, Aug 5, 2011 at 1:19 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 fas

RE: Estimation of repository upgrade

2011-08-05 Thread Bob Archer
> On Fri, Aug 5, 2011 at 1:19 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 i

Re: Estimation of repository upgrade

2011-08-05 Thread Mark Phippard
On Fri, Aug 5, 2011 at 1:19 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

RE: Estimation of repository upgrade

2011-08-05 Thread Bob Archer
> On Fri, Aug 5, 2011 at 12:19 PM, Bob Archer wrote: > >> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer > 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 re

Re: Estimation of repository upgrade

2011-08-05 Thread Nico Kadel-Garcia
On Fri, Aug 5, 2011 at 12:19 PM, Bob Archer wrote: >> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer 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

RE: Estimation of repository upgrade

2011-08-05 Thread Bob Archer
> On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer 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

Re: Estimation of repository upgrade

2011-08-05 Thread Giulio Troccoli
On 05/08/11 17:11, Nico Kadel-Garcia wrote: On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer 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 (bec

Re: Estimation of repository upgrade

2011-08-05 Thread Nico Kadel-Garcia
On Fri, Aug 5, 2011 at 10:58 AM, Bob Archer 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

RE: Estimation of repository upgrade

2011-08-05 Thread Bob Archer
> On Fri, Aug 5, 2011 at 10:11 AM, Giulio Troccoli > wrote: > > > On 05/08/11 14:18, Mark Phippard wrote: > > On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli > > wrote: > >    I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. > >  

Re: Estimation of repository upgrade

2011-08-05 Thread Mark Phippard
On Fri, Aug 5, 2011 at 10:11 AM, Giulio Troccoli < giulio.trocc...@mediatelgroup.co.uk> wrote: > > > On 05/08/11 14:18, Mark Phippard wrote: > > On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli > mediatelgroup.co.uk > giulio.troccoli@**mediatelgroup.co.uk>> >> wrote: >> >>I'm working on a pla

Re: Estimation of repository upgrade

2011-08-05 Thread Andy Levy
On Fri, Aug 5, 2011 at 10:11, Giulio Troccoli wrote: > > > On 05/08/11 14:18, Mark Phippard wrote: >> >> On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli >> > > wrote: >> >>    I'm working on a plan to upgrade our server from 1.4.6 to 1.6.17. >> >>    We

Re: Estimation of repository upgrade

2011-08-05 Thread Giulio Troccoli
On 05/08/11 14:18, Mark Phippard wrote: On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli > 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

Re: Estimation of repository upgrade

2011-08-05 Thread Mark Phippard
On Fri, Aug 5, 2011 at 7:09 AM, Giulio Troccoli < giulio.trocc...@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 esti

Re: Estimation of repository upgrade

2011-08-05 Thread Andy Levy
On Fri, Aug 5, 2011 at 07:09, Giulio Troccoli 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" co

Estimation of repository upgrade

2011-08-05 Thread Giulio Troccoli
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