On Thu, 26 Feb 2009, Magnus Torfason wrote:
>> - Should a server attempt to "fix up" an affected WC? This is probably
>> possible if the client is obliterate-aware, i.e., 1.7+ or whatever, and
>> depending on the answer to the previous "dimension". Probably not
>> possible for svn 1.0 - 1.6 clients. (And then there's the question, if
>> the server tells a 1.7+ client to obliterate its copy of a file, what
>> to do if the file is locally modified - but that is a detail.)
>
> Ahh, yes, great minds think alike. I have actually performed tests,
> simulating a pre- and post-obliteration repository, to see how existing
> clients deal with it, and posted the results to the list earlier today.
> That post has not showed up yet (possibly because it has attachments),
> but the answer is that client behavior is not catastrophic but not
> graceful either.
>
> Since I have never seen any push-type operations by the server, I have
> always though of this question being "should the client, upon seeing
> that the server data is not what the client expected to see, attempt to
> fix up the WC". And in my mind, this is *exactly* the distinction
> between OFFLINE obliteration (screw the WCs, but change the repository
> UUID to ensure that they know they are screwed) and ONLINE obliteration
> (try to handle existing WCs gracefully).
I believe it is possible to trick pre 1.7+ clients to do the right thing
under the following assumptions:
1. An ABSOLUTE ONLINE obliterate keeps some minimum meta data about the
obliterate sets. That would be something like "file X existed from rY to
rZ" or "file X was changed in rY".
2. When doing an update clients tell the server "I have file X at rev Y,
please give me file X at rev Z". Then the server sends back the delta.
So when a client tells the server that it has a file which is in an
obliteration set the server can find out and send back the corresponding
command and data if needed. It might tell the client to delete the file,
or tell it to replace the whole file with new data. Additionally an
obliterate flag could tell 1.7+ clients to ignore modifications a user
might have made and to replace the file with a pristine copy.
Martin
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1235046
Received on 2009-02-26 22:50:05 CET