You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by James Ward <ji...@gmail.com> on 2008/09/25 20:02:18 UTC
Merge question
We use Subversion (version 1.5.1 (r32289)), but our baseline
maintainer (in another state) uses a different version control
system.
In January, they gave us a disk with baseline version 10.
In April, we gave them a disk with
revision 2591 = baseline version 10 + our changes.
Both sides develop in parallel.
In September, they gave us a disk with baseline version 11.
We want to merge our changes, revision 3020, with baseline
version 11. The first thing we did was put version 11 under
Subversion at URL/tags/11v1. Now we had two choices:
1. Take our changes from 2591 to 3020 and merge that
into URL/tags/11v1.
2. Take the changes from 2591 to 11v1 and merge into revision 3020.
We tried both approaches, and they both failed in the same manner.
Does anyone have a suggestion about what to try next?
About which approach is better?
What we tried (Linux, RedHat 5, csh):
1. Take our changes from 2591 to 3020 and merge that
into URL/tags/11v1:
cd ~
rm -rf src
svn co URL/tags/11v1/src
cd src
svn merge --ignore-ancestry URL/trunk/src@2591 URL/trunk/src@3020 .
svn: Cannot replace a directory from within
2. Take the changes from 2591 to 11v1 and merge into revision 3020:
cd ~
rm -rf src
svn co URL/trunk/src
cd src
svn merge --ignore-ancestry URL/trunk/src@2591 URL/tags/11v1_2/src .
svn: Cannot replace a directory from within
Thank you for all your help!
Sincerely,
Jim Ward
RE: Merge question
Posted by Tennebø Frode <fr...@saabgroup.com>.
:
> 1. Take our changes from 2591 to 3020 and merge that
> into URL/tags/11v1.
>
> 2. Take the changes from 2591 to 11v1 and merge into revision 3020.
:
You forget the third option:
3) Take the changes from 10v1 (?) to 11v1 and merge into rev 3020 (I think you mean head):
cd ~
rm -rf src
svn co URL/trunk/src
cd src
svn merge --ignore-ancestry URL/tags/10v1/src URL/tags/11v1/src .
Of course this means that you need to have the entire 10v1 in svn and 11v1 as a delta. The way to do this is to import 10v1 in the usual way and use svn_load_dirs.pl to create the delta. Soemthin like this:
(The directories ./10v1 and ./11v1 contains the source as delivered from the vendor)
svn import ./10v1 URL/vendor/current
svn copy URL/vendor/current URL/vendor/10v1 /usr/share/doc/subversion-1.4.4/svn_load_dirs.pl -v -t ./11v1 URL/vendor/current .
svn copy URL/vendor/current URL/vendor/11v1
(I used a vendor branch, replace with tags if that's the way you prefer this)
-Frode
--
^ Frode Tennebø | email: Frode.Tennebo@saabgroup.com ^
| SAAB Microwave Systems AS | Isebakkeveien 49 |
| N-1788 Halden | Phone: +47 45 24 99 39 |
| with Standard.Disclaimer; use Standard.Disclaimer; |
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion 1.4.6 -> 1.5.2 migration - sanity check please
Posted by Andy Levy <an...@gmail.com>.
On Fri, Sep 26, 2008 at 08:55, David Aldrich <Da...@eu.nec.com> wrote:
> Hi
>
> We are planning to upgrade our svn server from 1.4.6 to 1.5.2. We are
> checking what is necessary to be done and would be grateful for comments on
> our plan.
>
> We have multiple repositories (one for each of our projects) in FSFS format.
>
> The plan is:
>
> 1) Install svn 1.5.2 onto new server hardware, running under Centos 5.0
>
> 2) Notify users and disable access to 1.4.6 server
>
> 3) Backup each repository using 'svnadmin dump' (or could use tar - I) and
> restore onto the new server
>
> 4) Run both svnadmin upgrade and svn-populate-node-origins-index on each
> repository
If you use svnadmin dump in 1.4.6 on the old server and svnadmin
create + svnadmin load in 1.5.2 on the new server, then step 4
shouldn't be needed.
> 5) Map existing http: url to point to new server
>
> 6) Notify users that new server is up and running.
>
> Users will remain at 1.4.6 client for now. I see no reason for them to
> commit modified files prior to the upgrade.
>
> Some file locks may be active, do we need to look after those in some
> special way?
Locks aren't maintained in the dumpfile. My personal preference would
be to get people to release all their locks (thus committing their
changes as well). I'm not sure if there's a "right" way to carry them
over.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please
Posted by Erik Hemdal <er...@comprehensivepower.com>.
> -----Original Message-----
> From: David Aldrich [mailto:David.Aldrich@EU.NEC.COM]
> Sent: Friday, September 26, 2008 9:40 AM
> To: Sholokhov, Vitaliy; users@subversion.tigris.org
> Subject: RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please
>
>
> Hi Vitaliy
>
> Thanks for your reply.
>
> > There's no reason to do such heavy lifting with migration
>
> Well, we want to move to new hardware, so it is appropriate for us.
>
> David
If you have the time, it's always nice to be able to check that you can
recover from a backup, move a repository, etc. Moving to new hardware gives
you a great opportunity to make sure everything is healthy.
I, for one, would appreciate hearing back if you run into anything
unexpected. Good luck with the upgrade.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please
Posted by David Aldrich <Da...@EU.NEC.COM>.
Hi Vitaliy
Thanks for your reply.
> There's no reason to do such heavy lifting with migration
Well, we want to move to new hardware, so it is appropriate for us.
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please
Posted by "Sholokhov, Vitaliy" <vs...@marvel.com>.
We've installed subversion 1.5 server on top of 1.4.6 without any
problems (while keeping repositories at 1.4 version).
There's no reason to do such heavy lifting with migration. It all works
out transparently.
P.S. Backups never hurt anyone in any case scenario ;-)
________________________________
From: David Aldrich [mailto:David.Aldrich@EU.NEC.COM]
Sent: Friday, September 26, 2008 8:55 AM
To: users@subversion.tigris.org
Subject: Subversion 1.4.6 -> 1.5.2 migration - sanity check please
Hi
We are planning to upgrade our svn server from 1.4.6 to 1.5.2. We are
checking what is necessary to be done and would be grateful for comments
on our plan.
We have multiple repositories (one for each of our projects) in FSFS
format.
The plan is:
1) Install svn 1.5.2 onto new server hardware, running under Centos 5.0
2) Notify users and disable access to 1.4.6 server
3) Backup each repository using 'svnadmin dump' (or could use tar - I)
and restore onto the new server
4) Run both svnadmin upgrade and svn-populate-node-origins-index on each
repository
5) Map existing http: url to point to new server
6) Notify users that new server is up and running.
Users will remain at 1.4.6 client for now. I see no reason for them to
commit modified files prior to the upgrade.
Some file locks may be active, do we need to look after those in some
special way?
Anything else we've forgotten?
Best regards
David
******************************************************************************
Nothing contained in this e-mail shall (a) be considered a legally binding agreement, amendment or modification of any agreement with Marvel, each of which requires a fully executed agreement to be received by Marvel or (b) be deemed approval of any product, packaging, advertising or promotion material, which may only come from Marvel's Legal Department.
******************************************************************************
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!
Subversion 1.4.6 -> 1.5.2 migration - sanity check please
Posted by David Aldrich <Da...@EU.NEC.COM>.
Hi
We are planning to upgrade our svn server from 1.4.6 to 1.5.2. We are checking what is necessary to be done and would be grateful for comments on our plan.
We have multiple repositories (one for each of our projects) in FSFS format.
The plan is:
1) Install svn 1.5.2 onto new server hardware, running under Centos 5.0
2) Notify users and disable access to 1.4.6 server
3) Backup each repository using 'svnadmin dump' (or could use tar - I) and restore onto the new server
4) Run both svnadmin upgrade and svn-populate-node-origins-index on each repository
5) Map existing http: url to point to new server
6) Notify users that new server is up and running.
Users will remain at 1.4.6 client for now. I see no reason for them to commit modified files prior to the upgrade.
Some file locks may be active, do we need to look after those in some special way?
Anything else we've forgotten?
Best regards
David
Re: Merge question
Posted by Andy Levy <an...@gmail.com>.
On Thu, Sep 25, 2008 at 16:02, James Ward <ji...@gmail.com> wrote:
> We use Subversion (version 1.5.1 (r32289)), but our baseline
> maintainer (in another state) uses a different version control
> system.
>
> In January, they gave us a disk with baseline version 10.
>
> In April, we gave them a disk with
> revision 2591 = baseline version 10 + our changes.
>
> Both sides develop in parallel.
>
> In September, they gave us a disk with baseline version 11.
>
> We want to merge our changes, revision 3020, with baseline
> version 11. The first thing we did was put version 11 under
> Subversion at URL/tags/11v1. Now we had two choices:
>
> 1. Take our changes from 2591 to 3020 and merge that
> into URL/tags/11v1.
>
> 2. Take the changes from 2591 to 11v1 and merge into revision 3020.
>
> We tried both approaches, and they both failed in the same manner.
> Does anyone have a suggestion about what to try next?
> About which approach is better?
>
> What we tried (Linux, RedHat 5, csh):
>
> 1. Take our changes from 2591 to 3020 and merge that
> into URL/tags/11v1:
>
> cd ~
> rm -rf src
> svn co URL/tags/11v1/src
> cd src
> svn merge --ignore-ancestry URL/trunk/src@2591 URL/trunk/src@3020 .
>
> svn: Cannot replace a directory from within
>
> 2. Take the changes from 2591 to 11v1 and merge into revision 3020:
>
> cd ~
> rm -rf src
> svn co URL/trunk/src
> cd src
> svn merge --ignore-ancestry URL/trunk/src@2591 URL/tags/11v1_2/src .
>
> svn: Cannot replace a directory from within
Strongly suggest you check out Vendor Branches in The Book.
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org