On Mon, 2009-10-05, Branko Čibej wrote:
> Julian Foad wrote:
> > These last few days I've been working down through the layers, looking
> > at a call graph something like this:
> >
> [...]
> > svn_fs_begin_obliteration_txn()
> >
> [...]
>
> > All of these APIs take a revision number as a parameter, and replace the
> > specified revision with a modified version of itself.
>
> Given that obliterate does everything differently from a normal
> transaction, do you really need an obliteration txn on the API level?
> you could really have a single svn_fs_obliterate(_path_rev) that handles
> the underlying txn management. Unless you're thinking ahead to issuing
> several obliterate commands in a single transaction; but in that case
> your whole call chain would have to be different, at least up to the RA
> layer.
That's an interesting question. Certainly there has to be a
"transaction" in the implementation in terms of "safe concurrent
changes". Does it need to be an "FS transaction" in the sense of
creating a new (replacement) revision? Well, here I'm still exploring
but it looks like this "FS transaction" model is a good fit for at least
part of the problem space. Some obliteration use cases are basically
within one revision, and I think we can serialize an "obliteration
commit" within one revision in the sequence of mostly "normal" commits
and maintain integrity while doing so.
See
<http://svn.collab.net/repos/svn/trunk/notes/obliterate/design-repos.html>. (I'll develop this explanation further.)
Does it need to be exposed in an API? I think the logic that decides
what changes need to be made within one revision should be higher level
than the fundamental "apply a change" API. At the moment it seems likely
that re-using the existing transaction-start and transaction-modify and
transaction-end framework is the most productive route. It depends
partly on how suitable the existing transaction-modify APIs are for an
obliteration transaction.
Is this the right API? The use case it doesn't cover efficiently is
"obliterate PATH from revisions 1 to 500000". One avenue to explore is
"obliterate the path history segment identified by the peg PATH_at_500000".
That might be a sufficiently large granularity to efficiently accomplish
an obliteration across a large revision range.
So I might well end up with a different form of transaction.
> Another question pops up: how do you obliterate a whole revision? the
> use case being, e.g., to undo the last commit. Would that be "svnadmin
> obliterate / HEAD"? How do we handle obliteration of directories in
> general -- I only recall files being mentioned.
Directories:
<http://svn.collab.net/repos/svn/trunk/notes/obliterate/design-repos.html> should help to explain it. The model of obliteration I'm using is per node, and applies equally to a directory-tree as to a file. It says, "Remove these nodes (files and/or directory trees) ... from revision R1, and these nodes ... from revision R2, and ...".
Obliterating a whole revision:
I am considering two models of obliteration. Both are per node-rev. The
model I call "dd1" is "delete PATH_at_REV...". The model I call "cc1" is
"undo the changes to PATH_at_REV", leaving the content of the PATH_at_REV+1
unchanged so that, after obliterating PATH_at_50, the changes originally
made in PATH_at_50 and PATH_at_51 will be combined in the change PATH_at_51.
In model "dd1", the way to undo a whole revision HEAD=r50 would be to
create a new revision r51 the way you want it and then obliterate
selected nodes from r50. (This would leave gaps in the history of any
affected nodes that already existed in r49 and still exist in r51.)
In model "cc1", the way to undo a whole revision HEAD=r50 would be
"obliterate ^/@50", which would replace the old r50 with a new r50 whose
file and directory tree content is an identical copy of r49's. (So the
change recorded by the new r50 is a null change.)
I do not intend to provide a way to remove a revision number from the
sequence of revision numbers, not even the head revision, neither by
renumbering subsequent revisions nor leaving a gap in the numbers. There
are several reasons why doing so would be troublesome, and I do not
think there are any use cases in which this would be particularly
useful.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2404028
Received on 2009-10-06 13:38:58 CEST