Many thanks for an instant reply, Thorsten! > > But in the meanwhile, someone commited in both repositories
> Doesn't this mean you ended up with revs 4477 to 4481 on the old repo > and loaded their content into the new repo as either new revisions, > increasing the revisions and changing content compared to the old > repo, or overwritten already existing revisions, changing content in > new repo? It happened like that: old machine: 4476(Filip1) -> 4477(Filip2) -> 4478 (Vik1) -> 4478 (Vik2) new machine: 4476(Filip1) -> 4477(Petra) So i did an incremental dump from 4477 to 4478 on the old machine and loaded it to the new one, increasing the version number: merged one : 4476(Filip1) -> 4477(Petra) -> 4477(Filip2) -> ... It didn't smell right, I must say :) > Both repos share the same base until rev 4477 and how should > subversion afterwards merge the differences during a load? > Would this work if the changes of the revisions in the both repos are > completely independent? I really do not know - would it work? The chance the changes collides are quite small as it is quite large repository. > I would very more about the repos, than the working copies, therefore You know users.. they are bitchy about checkouting large repo. I tried to avoid that. > if I could recover a consistent base from backup I would choose that, > let the devs move their current working copies out of the way, > re-checkout and afterwards would try to re-commit as much as possible. > > > So my question is basicly what happens when they have commits in their local > > working areas that will not on the server when I finish the recovery from > > tapes? > > In this case they all have to re-checkout. I thought so... it's a bit an irony i end up exactly where i didn't wanted to :) Many thanks again, Mojmir
