David, you've hit the nail on the head, imho.
Apart from all the oddities that David mentions, what are the *real*
needs for obliterate? I can only think of a few...
1. Recover disk space. Hmmm ... at $1/GB ???
2. Clean-up after an accidental commit of files that should not be in
the repo. Well, what's wrong with SVN RM? Sure, the files are around in
an old revision, but see #1 for my comments on that!
3. Delete a file that contains sensitive data that should not have been
in svn (e.g. encryption keys, atom bomb plans) in the first place. Well,
if sensitive data gets in svn "by mistake" I'd say you had broader
problems than just lack of obliterate.
Most importantly, as David notes, obliterating a file can have
ripple-through effect on other parts of a repo.
My vote on obliterate is NO.
--Tim
Weintraub, David wrote:
> On Tue, 2005-04-12 at 16:18 -0300, Nicolás Lichtmaier wrote:
> >Please read over
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=516
> >
> >to see the complexities of 'obliterate', and why we haven't
> >gotten around to it yet. It's not impossible to implement,
> >but some specification work is needed first.
>
> A few unsolicited comments...
>
> * First of all, I agree with Ben Collins-Sussman. This should be done
> through svnadmin and not through the svn client. Users have no reason
> to be able to access a command that does irreversible damage to the
> archive.
>
> * As mentioned by Karl Fogal, there are at least two separate commands
> being talked about. Command #1 removes a particular version of the
> file/archive (let's call it "rmver"). Command #2 removes all entries
> to a particular file from all versions of the archive (let's call it
> "obliterate").
>
> * In my 20 years of CM experience, the "obliterate" command isn't as
> important as the "rmver" command. Very rarely is there a need to
> completely remove all references to a particular file. The only time
> that ever happens is when a user accidently creates a file they didn't
> need.
>
> * Unlike other version control systems. Subversion versions not the
> file, but the archive. When I decide to remove the version of file
> "foo.txt" that exists in version 33 of the archive? What should I
> remove? Am I removing the entire version 33 of the archive. That is,
> you have version 32 and version 34, but not version 33? Or, am I
> removing the version of "foo.txt" that existed in version 33 of the
> archive?
>
> Let's say that "rmver" removes the entire version of an archive (which
> might be simpler to implement). If foo.txt was changed in versions 23,
> 33, and 45 of the archive, and I remove version 33 of the archive,
> what does version 34 of the archive look like? Do I see version 32 of
> the archive, plus any changes done in version 34 of the archive? Does
> that mean that foo.txt is the same file from version 23 to version 44
> of the archive? What if I also changed bar.txt in version 33 of the
> archive, and I wanted to keep that?
>
> Let's say that "rmver" removes only the version of the file that
> existed in that version of the archive. Let's also say the foo.txt
> changed in version 23, 33, and 45 of the archive. So, we can remove
> the version of foo.txt that existed in version 33 of the archive, but
> not necessarily bar.txt that existed in version 33 of the archive.
> What do we see when we look at version 33 of the archive? Do we see
> foo.txt at all? If not, what happens if you looked at version 34 of
> the archive? Or version 43 of the archive? If you simply "hide"
> foo.txt from view, you'll be missing this file in 10 different
> versions of the archive. If I am doing rmver for various files, I
> might get to the point where my archives become garbage because each
> version of the archive is missing files.
>
> * I label releases in Subversion by copying a pointer of a particular
> version of the archive to the tags directory -- which in turn creates
> another version of the archive. What if I copied version 36 of the
> archive to this directory as a release, and I removed the version of
> file foo.txt that existed in version 33 of the directory? If foo.txt
> wasn't changed between version 33 and version 44 of the directory,
> what does my labeled release look like? Do I still show version 33 of
> the file in the tags directory? Or, do I show the older version of
> foo.txt that existed back in version 23 of the file?
>
> This is a tricky answer because I might want diffent behaviors whether
> I did a copy of that version to the tags subdirectory (and thus is a
> labeled version of the file) or to the branches subdirectory (and thus
> is merely old development work and something I might not care about
> six months down the line).
>
Received on Thu Apr 14 21:33:56 2005