Scott Palmer wrote:
>
> On Apr 18, 2005, at 2:27 PM, Tim Hill wrote:
>
>> OK, so which "foo.c" revisions do I obliterate? Clearly I can work
>> backwards through time, killing all the foo.c revisions before the
>> specified revision. Should I also work "forwards", so if I obliterate
>> foo.c rev 10, should I also delete rev 11, 12 etc? I think the answer
>> is "yes", since (a) that's what "obliterate" means, (b) what exactly
>> do these orphanedrevisions mean anyway and (c) it's very hard to
>> preserve these given the structure of repos (particularly fsfs).
>
>
> I think the answer doesn't have to be yes. Since you can choose the
> correct revision to obliterate from and if done on the head obliterate
> can include an implicit 'rm'.
There is an implementation issue here: since fsfs repos use forward
deltas, it will become necessary to fixup revisions so that the next
revision up sees the correct content. This means that obliterating at
(say) rev 10 must also fixup the rev 11 revision. You would also have to
do some repo fixup to change an "edit" operation into an "add" operation
at rev 11.
>
>> So, we assume that foo.c gets deleted forward from a revision to its
>> own "head" revision, and backwards toward it's first "svn add". What
>> about renames? Should I trace backwards across renames? Scenario: Mr.
>> "Nasty" is about to be fired and knows it. He renames a
>> project-critical file to "oops.c", and commits. Then he tells his
>> admin: "Hey, I just commited oops.c by mistake!". No problem, says
>> the admin, and obliterates it. BUT obliterate tracks the rename, and
>> actually kills the project critical file! Remember, it's
>> "obliterate", so there is no going back: *none* (except for backups).
>
>
> There is a reason that the admin is the one to do this. They can
> first check that they have the file backed up, they can export a copy
> just to be safe, etc. The problem of being 'fooled' into destroying
> critical work is beyond the scope of the obliterate command.
>
>> What about branches? If I'm going "up" the tree (from older revs to
>> new), do I follow all the branches, obliterating all branches copies?
>
>
> That could be an option. (By that I mean a command line switch not
> just a potential implementation.) But for the first go I think that
> manually obliterating from branches is acceptable.
>
>> If not, how can I make sense of the fact that a file will exist in a
>> branch but has no prior existence? It will seem to appear in the
>> branch from nowhere.
>
>
> Did anyone read my ideas earlier in the thread about a possible
> implementation?
> The file could appear as a copy with modifications from an earlier rev
> that is 0 bytes in size. That is, the file in the trunk was
> obliterated, but there could be a placeholder file left there to keep
> other bits of the repo structure sane, the branch copy can be reworked
> to show the history as coming from the placeholder file but having the
> entire contents added.
> I'm not sure if that makes sense, but it seems like a good starting
> point for further discussion.
How would the 0 byte idea work for multiple branches? At the first
branch (working backwards) I might be able to do this, but then I have
to propogate *that* 0 byte file backwards to the previous branch, and
inject a fixed-up add at the branch point for *that* branch. So the end
result is I end up with a whole bunch of 0 byte files all over the place
with curious histories. Frankly, that doesn't sound much like
"obliterate" to me :)
>
>> Branches are even worse going backwards through revisions. What do I
>> do at a branch point? Again, I cannot ignore it, because if I do I'll
>> create orphans. So I have to follow "up" the branch as well.
>> Essentially, to ensure a coherent repo, I'm forced to trace from one
>> revision of foo.c to all others both up and down the branch tree, and
>> delete them all.
>
>
> I don't think it *has* to work like that. Obliterate *could* 'stop on
> copy' and require further obliterates to completely expunge the data.
> It certainly gets complicated when considering the entire graph of
> paths and revisions that any one file might 'touch' - but generating
> that tree should be possible and once you have it it should also be
> possible to deal with it in a reasonable manner - following copies or
> not as needed. I think obliterating backwards from leaf nodes makes
> the most sense... continuing until it hits a 'fork'.
>
> Obliterating earlier (non-leaf) revisions could work as if the path
> still exists but has no content from earlier revisions up to and
> including the obliterated revision, and after that the diff needs to
> be rewritten to include the entire contents of the file for rev+1.
Again, this is scary -- obliterate is actually turning into a wholesale
re-write of big chunks of metadata/content. I can only really see
obliterate working as a "prune" tool: obliterate everything backwards to
a given revision, including all branches above that revision, so that
entire trees are removed. I think this can be made to work, and I'm not
sure what the scanarios might be for wanting to do any other type of
obliterate.
>
>> 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.
>
>
> Well without hooks tags aren't invariant anyway :)... but if you make
> obliterate *only* follow the tree backwards, then as long as you
> didn't obliterate the file from the tag, then it would remain. That
> would also mean that you have to be explicit about obliterating a
> tagged file so you would consider then if that is what you really
> wanted to do.
>
> I like the idea of making obliterate only work backwards because often
> the 'bad' data might have already been replaced in a newer rev. So it
> would be nice to keep the file as it is from rev+1 on.
>
> The way I envision it, obliterate could take two rev numbers e.g.
> -rHEAD:1234 and (perhaps implicitly) --stop-on-copy.. Allowing
> multiple invocations to trim the tree as needed. If there are no
> branches the data can be obliterated in one go.
>
> Scott
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 18 23:12:34 2005