From: Tim Hill [mailto:tim@realmsys.com]
>
> Basically, what obliterate has to do is kill *all* revisions of
> foo.c, regardless of renames, throughout the entire branch tree.
> Note that this will include tags also, which means that tags are no
> longer invariant. Now *that* I find scary -- which is what puts me
> off having this feature.
Quite scary. I think that comes from specifying behaviour in terms of
the implementation, not in terms of the user-level abstraction.
In terms of the user-level abstraction, where a repo is an array of
filesystem trees, obliterate could be defined as a rm on a range of
virtual trees. Something like this pseudocode:
def obliterate(obliteratepath, fromrev, torev):
create a new, empty repository and check out to wcnew
for each revision in the old repository:
check out the full tree of that revision to wcold
comment = the commit comment for the revision
if fromrev<=revision<=torev:
modify wcnew to match wcold
rm obliteratepath in wcnew
if obliteratepath existed:
comment = patchcomment(comment, obliteratepath)
commit wcnew -m comment
optionally patch the GUID of newrepo
replace sourcerepo with newrepo
def patchcomment(comment, obliteratepath):
if there is a obliteration-comment hook:
return delegate-to-hook(comment, obliteratepath)
else:
return comment + '\nObliterated: ' + obliteratepath
This is just for specification purposes, obviously a concrete
implementation following this approach would be much, much slower than
an implementation mucking with the DB directly could be, and use
inordinate amounts of temporary disk space too.
- Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 19 14:45:50 2005