At 2:42 AM -0500 7/24/07, Ryan Schmidt wrote:
>
>We must consider that FSFS repositories currently enjoy the property
>that revision files are immutable once created, and this property
>has been assumed by some backup scripts, probably both the official
>released scripts and some that have been home-grown. If we implement
>obliterate such that revision files are still immutable, then we
>have not truly implemented obliterate since the data is still there
>-- even if we tell Subversion to ignore it.
This comment reminds me: What I would like in an 'obliterate' is
something that removes all the data of a commit, but still keeps
some record of it. I.e., keep some of the meta-data of the commit,
instead of removing every indication that the commit ever happened.
I think this would be a big advantage of an official, well-designed
'obliterate'.
I'm not sure how that would be done in practice. But I don't want
the revision-number to disappear. And I want both the original log
message and the obliterate operation to appear in 'svn log' as
something like:
---------------------------------------------------------------------
r243 | gad | 2007-03-06 23:02:29 -0500 (Tue, 06 Mar 2007) | 7 lines
RM | gad | 2007-03-10 23:02:29 -0500 (Tue, 06 Mar 2007)
Orig:
Make an important change do to great stuff.
Obliterated:
OMG, I committed a dvd disk-image instead of the 7-line Makefile fix!
---------------------------------------------------------------------
And since I expect the date on that revision # would not change, I'd
also imagine a new revision # with a log-entry at the time the
obliterate command was done. So, the details on the obliterate
would show up in multiple places.
The idea is to leave behind plenty of evidence that the obliterate was
done, even though svn would complete remove the original change. Among
other things, this would discourage people from using obliterate for
frivolous reasons. If there's going to be all that evidence that the
obliterate was done, then people aren't going to bother doing it just
because "they were embarrassed" due to a bug in some broken code that
they committed.
>Consider a scenario in which a file is added to the trunk in r10,
>copied to branch1 in r20, copied to branch2 in r30, and modified in
>all three instances at various points in between and after. You now
>ask svnadmin to obliterate r15:35. What happens if you specify the
>file in trunk? Does it affect the other two files? What if you
>instead specify the file in branch1? What if you specify the one in
>branch2? I don't know the answers, I'm just saying svnadmin will
>need to know them before this can be implemented. Or, as a shortcut
>for an initial implementation, we could say that a file that has
>been copied cannot be obliterated.
This would be good enough for an initial implementation, IMO, as
long as people could get around this by *first* using obliterate
on all the copies, and then obliterating the original change.
I'm sure it would still be a significant amount of work to get all
the details right, but it would be nice to have for the few times
one really needs an obliterate-like function.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 24 21:22:47 2007