Folker Schamel wrote:
> Nik Clayton wrote:
[...]
>> A few hours later (after being woken up at unfriendly time of the
>> morning), one of the master repository managers directly edited the
>> underlying ,v files -- the new files were completely removed, the
>> modified files were reset so that not only did the commit never happen,
>> there was no trace of the commit ever happening.
>
> You want "svn obliterate" to not work on per-file basis,
> but on per-commit basis?
Yes. If a particular commit contains a mix of files that we are allowed
to distribute and files that we're not allowed to distribute it is
simpler to obliterate the commit, and then recommit the correct files.
This also handles the case where bad code is committed to a file that
previously existed. I wouldn't want to remove that file from the entire
repo history, I just want to remove that change.
> What should "svn obliterate" do if a later regular commit
> affects the same file as the inadvertent commit?
Consider a repo that contains foo.c at r1. Someone inadvertently
commits proprietry code to foo.c at r2, and then someone else comes
along and commits more code to foo.c in r3.
I'd like r2 to disappear. By this I mean that the delta of the change
between r1 and r2, and between r2 and r3, in this repo (and any repos
synced from this repo) must not contain the proprietry code[1].
If the changes in r2 and r3 did not affect the same lines in the file
(i.e., there's no conflict) then this is probably quite simple. Just
flag r2 as being 'empty', and make sure the delta is 'empty' (padded
with NULs, or similar).
This might leave you with a 'bad' file, in the sense that the code might
no longer compile -- perhaps r2 included a new function, and r3 contains
code to call the function. But this is no different from a botched
merge, and can be worked around in subsequent commits.
If the changes in r2 and r3 are dependent (say r2 adds a function, and
r3 modifies that function) then "svn obliterate" should detect this, and
warn the user with a list of all the dependent revisions, and then exit.
% svn obliterate -r 2 $REPO
Revision 3 depends on revision 2
Cannot remove revision 2 due to dependent revisions
There are probably two ways to handle what then has to happen.
Either "svn obliterate --force" could then be used. The effect would be
to obliterate the requested revision, and any revisions that depend on it.
% svn obliterate --force -r 2 $REPO
Revision 3 depends on revision 2
Obliterated revision 3
Obliterated revision 2
Or, the user runs "svn obliterate", and passes it the complete list of
revisions identified. The command removes the revisions in order,
youngest first
% svn obliterate -r 2 -r 3 $REPO
Obliterated revision 3
Obliterated revision 2
Swapping the order of the -r options should have no effect.
These examples use 'svn', but I would be happy if this was only
available through 'svnadmin'.
N
[1] I.e., not only should it be impossible for tools built on top of the
client API to see the change, it should be impossible to create a tool
that uses the SVN filesystem API to extract the change either. If the
change still lives in the repo somehow then we're still technically
distributing code that we have no license to distribute.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 12:23:06 2006