On Mon, Oct 15, 2012 at 5:44 PM, Thorsten Schöning <tschoen...@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.
