Used hotcopy for Windows to Linux migration, any problems?

[communitybot <co...@googlemail.com>]

Hi,

A week after our Windows to Linux repository migration using "svnadmin
hotcopy" we realised we couldn't edit revision properties; this was because
the pre-revprop-change hook script was in DOS (CRLF) format.

My question is what other problems should we expect having moved from
Windows to Linux hosting using "svnadmin hotcopy" for the migration?

Further detail:

We moved our repository from a Windows host to a Debian Linux host under
VMware. I had assumed that using a hotcopy would be appropriate for the
migration since we were running the same version (1.4.2) on the two hosts.
On reflection that was a mistake as the recommended procedure is dump/load,
but we haven't noticed anything wrong so far other than the aforementioned
problem.

As a side note, we found Subversion 1.4.2 on Debian under VMware to be 25%
faster than running the same version natively on the very same Windows
Server 2003 machine.

Thanks!

Re: Used hotcopy for Windows to Linux migration, any problems?

[communitybot <co...@googlemail.com>]

2008/6/13 Florian Seydoux <fl...@gmail.com>:

> communitybot wrote:
>
>>
>> [...]
>> Given the minor problem about revision property changes we had to fix, and
>> bearing in mind that we now have one week's commits in the new repository,
>> along with revprop changes, I would like to know if anyone can suggest any
>> potential problems to look out for or any action to take.
>>
>
> Hi,
> except adapting *all* hook scripts (for notification, incremental copy,
> etc.),
> as well as those for regular backup (cron), nothing special.


That's what I want to hear :)


>
> But you can also profit of the possiblity given by the linux "box" to do
> additional things
> (or, at least, in a much easy way): on-the-fly compression of the
> incremental (post-commit),
> rotation of the server's logs (if any); you can also profit of the
> subversion-tools components,
> like the really efficient svn-fast-backup).
>

Currently we have a very simple setup with no hooks other than the mandatory
pre-revprop-change but will be taking advantage of the VMware image to run a
backup read-only repository and use hooks to keep it up to date. You make a
good point about the additional possibilities - I will look into these.

Thanks.

Re: Used hotcopy for Windows to Linux migration, any problems?

[Florian Seydoux <fl...@gmail.com>]

communitybot wrote:
> 
> [...]
> Given the minor problem about revision property changes we had to fix, 
> and bearing in mind that we now have one week's commits in the new 
> repository, along with revprop changes, I would like to know if anyone 
> can suggest any potential problems to look out for or any action to take.

Hi,
except adapting *all* hook scripts (for notification, incremental copy, 
etc.),
as well as those for regular backup (cron), nothing special.

But you can also profit of the possiblity given by the linux "box" to do 
additional things
(or, at least, in a much easy way): on-the-fly compression of the 
incremental (post-commit),
rotation of the server's logs (if any); you can also profit of the 
subversion-tools components,
like the really efficient svn-fast-backup).

cheers,

flo



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Used hotcopy for Windows to Linux migration, any problems?

[communitybot <co...@googlemail.com>]

2008/6/12 Andy Levy <an...@gmail.com>:

> On Thu, Jun 12, 2008 at 9:17 AM, communitybot
> <co...@googlemail.com> wrote:
> > Hi,
> >
> > A week after our Windows to Linux repository migration using "svnadmin
> > hotcopy" we realised we couldn't edit revision properties; this was
> because
> > the pre-revprop-change hook script was in DOS (CRLF) format.
> >
> > My question is what other problems should we expect having moved from
> > Windows to Linux hosting using "svnadmin hotcopy" for the migration?
>
> Your hook script issue was not because you used svnadmin hotcopy.
>
> When migrating a repository between OSes, servers, processor
> architectures, or BDB versions (though that changed at some point in
> the last year or two I think), you should use svnadmin dump and
> svnadmin load, NOT a plain hotcopy. This is outlined pretty well in
> the fine manual. See
>
> http://svnbook.red-bean.com/en/1.4/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate


Thanks for your reply. I am aware that the recommended procedure is
dump/load, although if the manual explicitly warns against using hotcopy for
this then I have misread it.

Given the minor problem about revision property changes we had to fix, and
bearing in mind that we now have one week's commits in the new repository,
along with revprop changes, I would like to know if anyone can suggest any
potential problems to look out for or any action to take.

Thanks.

Re: Used hotcopy for Windows to Linux migration, any problems?

[Andy Levy <an...@gmail.com>]

On Thu, Jun 12, 2008 at 9:17 AM, communitybot
<co...@googlemail.com> wrote:
> Hi,
>
> A week after our Windows to Linux repository migration using "svnadmin
> hotcopy" we realised we couldn't edit revision properties; this was because
> the pre-revprop-change hook script was in DOS (CRLF) format.
>
> My question is what other problems should we expect having moved from
> Windows to Linux hosting using "svnadmin hotcopy" for the migration?

Your hook script issue was not because you used svnadmin hotcopy.

When migrating a repository between OSes, servers, processor
architectures, or BDB versions (though that changed at some point in
the last year or two I think), you should use svnadmin dump and
svnadmin load, NOT a plain hotcopy. This is outlined pretty well in
the fine manual. See
http://svnbook.red-bean.com/en/1.4/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

> Further detail:
>
> We moved our repository from a Windows host to a Debian Linux host under
> VMware. I had assumed that using a hotcopy would be appropriate for the
> migration since we were running the same version (1.4.2) on the two hosts.
> On reflection that was a mistake as the recommended procedure is dump/load,
> but we haven't noticed anything wrong so far other than the aforementioned
> problem.
>
> As a side note, we found Subversion 1.4.2 on Debian under VMware to be 25%
> faster than running the same version natively on the very same Windows
> Server 2003 machine.
>
> Thanks!
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org