Re: svn repo corruption question

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
Received on 2012-12-04 17:43:10 CET