On Jul 23, 2007, at 10:26, patrick wrote:
> Cem Karan wrote:
>
>> svnadmin obliterate -r 123:145 myFile
>>
>> Other command forms would look like:
>>
>> svnadmin obliterate [-r M:N] sourceURL // Wipe out a specified range
>> svnadmin obliterate [-r :N] sourceURL // Wipe out everything up to
>> version N
>> svnadmin obliterate [-r M:] sourceURL // Wipe out everything starting
>> from version M through the most current
"-r :N" and "-r M:" are not consistent with existing svn and svnadmin
syntax, which is:
[-r LOWER[:UPPER]]
From "svnadmin help dump":
> Dump revisions LOWER rev through UPPER rev. If no revisions are
> given, dump all revision trees. If only LOWER is given, dump that
> one revision tree.
Using existing syntax, "-r :N" would be better expressed "-r 1:N" and
"-r M:" would be "-r M:HEAD".
>> svnadmin obliterate [-r M] sourceURL // Wipe out version M
>>
>>
> deleting a single revision makes it necessary to recalculate the
> delta for
> the version before or after (AFAIK DB and FSFS do deltas in opposite
> direction)
> deleting whole ranges makes it necessary to "sum up" these deltas.
Remember that it's not necessarily (and not necessarily only) the
immediately preceding or immediately subsequent revision that depends
on a given revision. See skip-deltas:
http://svn.collab.net/repos/svn/trunk/notes/skip-deltas
> i recon that the delta algorithm is already implemented so i guess
> it does
> not make the task a lot more difficult. (how about performance?).
>
> i can see the need for this function but IMO one could start with
> the real
> simple solution and have this added in a second iteration.
And what is "the real simple solution"?
We must consider that FSFS repositories currently enjoy the property
that revision files are immutable once created, and this property has
been assumed by some backup scripts, probably both the official
released scripts and some that have been home-grown. If we implement
obliterate such that revision files are still immutable, then we have
not truly implemented obliterate since the data is still there --
even if we tell Subversion to ignore it. And if we instead implement
obliterate such that old revision files get altered, then this has
implications for backup scripts, and indeed for backup strategy.
Consider a scenario in which a file is added to the trunk in r10,
copied to branch1 in r20, copied to branch2 in r30, and modified in
all three instances at various points in between and after. You now
ask svnadmin to obliterate r15:35. What happens if you specify the
file in trunk? Does it affect the other two files? What if you
instead specify the file in branch1? What if you specify the one in
branch2? I don't know the answers, I'm just saying svnadmin will need
to know them before this can be implemented. Or, as a shortcut for an
initial implementation, we could say that a file that has been copied
cannot be obliterated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 24 09:42:32 2007