[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Another request for obliterate...

From: Weintraub, David <David.Weintraub_at_ilex.com>
Date: 2005-04-12 23:52:35 CEST

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 Tue Apr 12 23:53:18 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.