Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of jan.keirse@tvh.com designates
 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1968789049.20121015174430@am-soft.de>
References: 
 <CAH=XL3cqCtMPQYR=6y8QTX3oxiqNhTNnULNM=G2cA6JEnXRd2A@mail.gmail.com>
 <1968789049.20121015174430@am-soft.de>
From: Jan Keirse <jan.keirse@tvh.com>
Date: Tue, 16 Oct 2012 15:17:05 +0200
Message-ID: 
 <CAH=XL3ci_ZvrkPANApi6mMDZLv4sC2-28qkEMnSupauVNxu_ew@mail.gmail.com>
Subject: Re: Merging repositories => UUID conflict
To: users@subversion.apache.org
Content-Type: multipart/alternative; boundary=047d7b6d8dae55fda304cc2cf95e

--047d7b6d8dae55fda304cc2cf95e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 15, 2012 at 5:44 PM, Thorsten Sch=C3=B6ning <tschoening@am-soft=
.de>wrote:

> Guten Tag Jan Keirse,
> am Montag, 15. Oktober 2012 um 16:08 schrieben Sie:
>
> > However, when I try to svn relocate the working copies from
> > repository B to repository A because the UUID is different between
> > the 2 servers. I had hoped I would be able to just relocate and
> > after an update svn would see nothing changed between the version
> > number increase and just accept it.
>
> But it's not just the version numbers different from repo B to A, all
> content before repo B was loaded into A is missing from working copies
> for repo B.
>

We don't have any checkout of the entire tree, but it does explain why
allowing this could get overly complicated.


>
> > - Is there a way to merge the repositories without having to
> > checkout all working copies again?
>
> You only need to checkout the working copies from that repo which was
> loaded into another one, because all other working copies just need
> updates. Else the answer is no.
>

Okay, that's clear.


> > - Is the concept of dumping a repository and loading into another
> > repository that already have revisions something safe?
>
> Yes, I did it myself some months ago for comparable reason like you:
> The content of B was better placed in A and I wanted to keep all the
> history of B.
>
> > Or is this
> > risky (one odd thing that's instantly visible is that revisions with
> > high numbers can be older than revisions with lower numbers?)
>
> It's only risky if you use tools which work on dates, not revisions,
> else devs need to know the fact of the merge to not wonder on such
> revisions, of course, but from my experience as development continues
> in the target repo of the merge there's no real problem as devs will
> focus on their newly created revisions.
>
>
Thanks for your feedback. We'll go ahead and do new checkouts.

--047d7b6d8dae55fda304cc2cf95e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 15, 2012 at 5:44 PM, Thorsten Sch=C3=B6ning <span dir=3D"ltr">&=
lt;<a href=3D"mailto:tschoening@am-soft.de" target=3D"_blank">tschoening@am=
-soft.de</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">

Guten Tag Jan Keirse,<br>
am Montag, 15. Oktober 2012 um 16:08 schrieben Sie:<br>
<div class=3D"im"><br>
&gt; However, when I try to svn relocate the working copies from<br>
&gt; repository B to repository A because the UUID is different between<br>
&gt; the 2 servers. I had hoped I would be able to just relocate and<br>
&gt; after an update svn would see nothing changed between the version<br>
&gt; number increase and just accept it.=C2=A0<br>
<br>
</div>But it&#39;s not just the version numbers different from repo B to A,=
 all<br>
content before repo B was loaded into A is missing from working copies<br>
for repo B.<br></blockquote><div><br></div><div>We don&#39;t have any check=
out of the entire tree, but it does explain why allowing this could get ove=
rly complicated.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>


<div class=3D"im"><br>
&gt; - Is there a way to merge the repositories without having to<br>
&gt; checkout all working copies again?<br>
<br>
</div>You only need to checkout the working copies from that repo which was=
<br>
loaded into another one, because all other working copies just need<br>
updates. Else the answer is no.<br></blockquote><div><br></div><div>Okay, t=
hat&#39;s clear.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div class=3D"im">


&gt; - Is the concept of dumping a repository and loading into another<br>
&gt; repository that already have revisions something safe?<br>
<br>
</div>Yes, I did it myself some months ago for comparable reason like you:<=
br>
The content of B was better placed in A and I wanted to keep all the<br>
history of B.<br>
<div class=3D"im"><br>
&gt; Or is this<br>
&gt; risky (one odd thing that&#39;s instantly visible is that revisions wi=
th<br>
&gt; high numbers can be older than revisions with lower numbers?)<br>
<br>
</div>It&#39;s only risky if you use tools which work on dates, not revisio=
ns,<br>
else devs need to know the fact of the merge to not wonder on such<br>
revisions, of course, but from my experience as development continues<br>
in the target repo of the merge there&#39;s no real problem as devs will<br=
>
focus on their newly created revisions.<br>
<br></blockquote><div><br></div><div>Thanks for your feedback. We&#39;ll go=
 ahead and do new checkouts. =C2=A0</div></div>

--047d7b6d8dae55fda304cc2cf95e--