Les Mikesell wrote:
> On Tue, 2006-09-05 at 11:50 -0700, Karl Fogel wrote:
>> Les Mikesell <lesmikesell@gmail.com> writes:
>>> I'd expect it to have exactly the same results as a dump/filter/load
>>> sequence back into the same location, in which case the feature is
>>> already defined and acceptable. We just need an implementation that
>>> is faster, doesn't need the intermediate copies, and doesn't break
>>> checked-out workspaces any more than necessary.
>>
>> Sure, any of the proposed behaviors in
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=516#desc17
>>
>> could be implemented via a dump/filter/load sequence, but that
>> doesn't specify which exact one you had in mind. Can you describe
>> it in terms of results, rather than of implementation?
>
> I still think in terms of the way CVS works so I'd want the effect
> of removing the file,v file from a CVS repository filesystem. That
> is, all versions completely gone at once. Perhaps this could be
> combined with a directory-level dump/filter/restore operation if you
> wanted to put back some subset of versions in its place.
I can see a need for obliterating an entire revision (user puts
sensitive data into a file & commits; need to get rid of the sensitive
info without getting rid of the file itself). This is option d) in Karl
Fogel's comment (link quoted above).
I can see a need for obliterating an entire file, complete with all
files that were copied from it (security guy points out that the
"encrypted" passwords that have been stored since rev 1 are simply
ROT-13'd). I believe this maps to Karl's option c, though maybe b.
This also seems to be what Les is desiring.
I'm not sure what the other two options Karl listed are; could someone
give plausible examples of each?
These two choices would seem to indicate that "svn obliterate" should
have multiple forms, to do different things:
1) "svn obliterate -r <rev>" should make svn act as if the changes in
revision <rev> never happened; checking out revision <rev> should give
the files as they appeared in revision <rev>-1, and any subsequent
revisions which are stored as deltas off of revision <rev> would have to
have their deltas recalculated. "svn up" on an existing working copy
should rollback the changes in the revision, potentially causing a
conflict.
2) "svn obliterate <file>" should remove the specified file, across all
revisions, following copies & renames. Since svn doesn't currently have
true renames, this may be tricky. Could potentially invalidate all
deltas, though marking the file as "obliterated" and delaying
recalculating the deltas until some convenient time (such as a dump/load
cycle) would help. "svn up" on an existing working copy should remove
the file if there haven't been any changes to it; otherwise, it should
become unversioned.
3) "svn obliterate -r <rev> <filename>" should (I think) remove changes
to the specified file in the specified revision, while leaving all other
changes in that revision intact. Revisions which are delta's off of the
specific revision would have to be recalculated. "svn up" would act
like case 1), above.
3a) An alternative interpretation of the command in case 3) would be to
totally remove the file from the specified revision/revision range,
which could be tricky, but I think the interpretation in case 3) would
be the more common one.
Other options?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 5 22:43:22 2006