Hi Peter, thanks for the comments, I do appreciate them.
Peter Samuelson wrote:
> [Magnus Torfason]
>> A TWO-BY-TWO CLASSIFICATION OF OBLITERATION TYPES
>>
>> At a high level, obliteration can be classified along two
>> dimensions. The ABSOLUTE vs. VIRTUAL distinction refers to whether
>> obliterated data is removed from disk or merely hidden. The
>> OFFLINE vs. ONLINE distinction refers to whether working copies
>> can continue to be used after an obliteration operation.
>
> Oh, there are more dimensions than that.
I know. There always are :-)
> - Does the obliterate function affect a file and its entire history, or
> does it simply "flatten" two revisions into one-plus-a-noop? The
> latter seems like it might be easier, and would be perfectly acceptable
> in the common case where a rev was immediately reverted.
This is very true, but my 2x2 is intended to be read in the context of
the functional specification, which addresses the above question in
terms of OBLITERATION SETS. Thus to "flatten" revisions 31 and 32 (in
the sense of making file_at_31 and file_at_32 be identical) one would specify:
OBL-SET = ^/path/to/file_at_32
After applying this obliteration set, @32 looks exactly like @31, but
@33 is unaffected. To obliterate an entire history, one defines:
OBL-SET = ^/path/to/file_at_0:HEAD
Since no file can come into being without being added at some point,
this obliterates the file. I am of course aware that a file may be
copied/moved. However, extending the core obliteration to allow such
functionality would be trivial, by defining an obliteration set that
contained the whole history of the file. This could even be left as an
"exercise for the reader" (i.e. implemented by any user, through svn log
and perl).
The OBLITERATION SET definition has not been committed yet, but I sent a
patch to the list in:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1135837
Thus, summarizing the above, I would collapse this dimension into a
single point, but being able to do so depends completely on thinking
in terms of these OBLITERATION SETS. I would very much appreciate
comments on that whole approach to the problem, because if it does not
go down well all my modifications to the functional specification will
have to be scrapped, since *everything* depends on the OBLITERATION
SET approach.
> - Is it OK for there to be evidence on the server side that a deleted
> file previously existed? (For the VIRTUAL case, obviously yes, it is
> acceptable.) Which characteristics - pathname, size, checksum, etc. -
> are acceptable to retain? Or does it all need to be wiped clean? This
> may sound like a petty detail, but it has important implications for
> gracefully handling affected WCs.
I had thought about this in the context of auditing, and in that context
my answer is "whatever", since Subversion is not an auditing tool.
I had *not* thought about this in the context of gracefully handling
affected WCs. This is a very important issue, and I would really like to
hear your thoughts on this in more detail.
I would like to note that any properties visible on the server but not
on the client could be cleaned out by doing a svnsync operation, which
is actually pretty close to how I have envisioned an ABSOLUTE
obliteration being performed, so I guess my current idea is that all
file meta-data disappears in an ABSOLUTE obliteration.
> - 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).
Best,
Magnus
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1234644
Received on 2009-02-26 21:32:56 CET