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'.
> 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.
> 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.
> 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
Received on Mon Apr 18 22:01:43 2005