Gale, David wrote:
> 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.
Cases 1 & 3 seem difficult to perform reliably. What if a subsequent
delta depended on the changes made in the revision to be deleted? It
might be impossible to recalculate the diffs.
Case 2 includes issues about renames and file copies, which may,
as noted, be problematic.
There appear to be multiple problems masquerading under the same
name. The problems for which these three cases are proposed
solutions are really not the same as the problem I'd like to see
addressed. My problem is not undoing a revision.
My problem is simpler: files are checked in which should not have
been. I want to delete these unwanted files from the repository.
This may be a case of the perfect being the enemy of the good.
I make no pretense that my problem or its solution would
solve any of the more complex possible problems which one might also
want to address. But addressing these problems isn't necessary
in order to address the problem I want to solve.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 5 23:10:26 2006