On Mon, Oct 15, 2012 at 5:44 PM, Thorsten Schöning <tschoening_at_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.
Received on 2012-10-16 15:17:55 CEST