RE: Re: Another request for obliterate...

As part of my duties I am a network admin. I hear "Disk space is so cheap, just add more" a LOT. It's not a true statement or at least vastly misleading. Sure, the physical disk is cheap (although not as much with SCSI, which is still the most popular server disk type). You still have to "pay" the admin to add it to the server/raid array which can take hours or more in some setups. You have to figure out a backup system for that extra disk which can be non-trivial. In fact, an increasing number of admins that I talk to are capping their network disk space because of backup constraints rather than anything else. If you can't afford SAN mirroring or something like that then you're stuck with tape for backkup and tape is EXPENSIVE, both in administration and in media cost.
 
While I have no opinion on the obliterate question, I had to speak on what I consider to be a point that has no weight in the argument.
 
Rick

________________________________

        From: Tim Hill [mailto:tim@realmsys.com]
        Sent: Thursday, April 14, 2005 3:32 PM
        To: Weintraub, David
        Cc: users@subversion.tigris.org
        Subject: Re: Another request for obliterate...
        
        
        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 22:28:39 2005