[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issues Loading a svn 1.4.2 dump on another server running 1.6.5 ?

From: Andy Levy <andy.levy_at_gmail.com>
Date: Fri, 28 Aug 2009 09:59:42 -0400

On Fri, Aug 28, 2009 at 09:57, Phil Pinkerton<pcpinkerton_at_gmail.com> wrote:
>
>
> On Fri, Aug 28, 2009 at 9:52 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
>>
>> PLEASE Reply To ALL to keep discussion on-list.
>>
>> On Fri, Aug 28, 2009 at 09:45, Phil Pinkerton<pcpinkerton_at_gmail.com>
>> wrote:
>> >
>> >
>> > On Fri, Aug 28, 2009 at 9:27 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
>> >>
>> >> Please Reply to All so the whole list sees your replies, not just me.
>> >>
>> >> On Fri, Aug 28, 2009 at 09:24, Phil Pinkerton<pcpinkerton_at_gmail.com>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Fri, Aug 28, 2009 at 9:12 AM, Andy Levy <andy.levy_at_gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> On Fri, Aug 28, 2009 at 09:07, Phil Pinkerton<pcpinkerton_at_gmail.com>
>> >> >> wrote:
>> >> >> > I have a client that insists he needs to keep his svn 1.4.2
>> >> >> > repository,
>> >> >> > but
>> >> >> > he wants it moved to a new server that is running svn 1.6.5.
>> >> >> >
>> >> >> > Will the load maintain the 1.4.2  version on the 1.6.5 server ?
>> >> >>
>> >> >> svnadmin dump only keeps the data, not the repository format or the
>> >> >> Subversion libraries themselves.
>> >> >>
>> >> >> svnadmin dump/load will migrate his data to the new server, but it
>> >> >> will be running Subversion 1.6.5 and have all the latest features,
>> >> >> like FSFS directory sharding & packing, merge tracking, etc. Unless
>> >> >> he
>> >> >> has a very good reason to stick with 1.4.2 (like a bug in 1.6.5 that
>> >> >> does not exist in 1.4.2), the upgrade is a good thing.
>> >> >
>> >> > I agree, however they are afraid the svn tools and plugins they
>> >> > currently
>> >> > use will not function on 1.6.5.
>> >>
>> >> Those fears are most likely unfounded, unless they're using API
>> >> functionality that has significantly changed (which shouldn't happen),
>> >> they went directly to the repository database instead of using the
>> >> API, or they relied upon buggy behavior which has been fixed.
>> >>
>> >> > Another alternative is they have an older test repo that was created
>> >> > as
>> >> > 1.4.2, then the server was upgraded to 1.6.5. so perhaps there is a
>> >> > way
>> >> > to
>> >> > update the the older 1.4.2 repo that resides on the upgraded 1.6.5
>> >> > server
>> >> > using the data on the current 1.4.2 server ?
>> >>
>> >> I have no idea what you're trying to say here.
>> >
>> > ok
>> >
>> > Test Server A Repository was originally created using Subversion 1.4.2
>> >
>> > Prod Server B Repository was originally loaded from a Server A dump
>> > (1.4.2)
>> >
>> > Prod Server B Repository was used for six months with Subversion 1.4.2
>> >
>> > Test Server A was upgraded to 1.6.5 ( the Repository was not upgraded )
>> >
>> > They want to test the latest Prod Server B 1.4.2 repo data on the
>> > Upgraded
>> > Test Server A.
>> >
>> > So I need to get 1.4.2 data from B to A
>> >
>> > Any clearer ? sorry for the confusion.  and btw thanks for you quick
>> > responses
>>
>> The dumpfile format allows for the exchange of any repository between
>> any 1.x version. So yes, you can dump from 1.6.5 and load into 1.4.2.
>
>
> What I need to do is dump a 1.4.2 repo that is on a 1.4.2 server and load it
> into a 1.4.2 repo that is on a svn 1.6.5 server.

So you want to have 2 versions of SVN installed on the same server?
That's just going to lead to trouble and confusion.

If you create a repository with 1.6.5, it will be be in the format used by 1.6.x

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388268

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-28 16:00:50 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.