Re: Delete *for real* from a repository

One thing I tell users of Subversion is NOT to store binary data in your
repository. If you can build it, don't store it. Obliterating revisions in
text files in Version Control doesn't save a whole lot of space. However,
binaries take up a ton of room -- especially already compressed binaries.
Subversion does to a binary diff, but I am not convinced it saves that much
room. Perforce, for example, doesn't bother with diffing binaries. They
simply compress them.

So, if you're storing binaries in your repository that are either being
built by you or can easily be retrieved elsewhere, the best advice, if you
have Subversion, is to stop. We use Nexus which is a Maven repository
manager and Hudson to store binaries we build. We use Maven and Ant/Ivy to
retrieve these revisions from Nexus when we need them for a build.

Maven is certainly an overkill for this. It is certainly a difficult piece
of software to learn, and documentation is weak, but it does allow us to
version binary files outside of our Subversion repository.

There's a lot of difficulty in an "svn obliterate' command. For example, I
changed a dozen of files in revision 1234 including foo.java. I obliterate
revision 1234 of foo.java, what does the rest of revision 1234 now look
like. Does it contain foo.java 1233 or foo.java 1235? What if I did a copy
of revision 1234 to a tag or branch? How would that be affected?

John Loyd refers to himself as an "ignostic". He refuses to be drawn into a
debate about God's existence until all the terms are well defined. We have a
similar issue with an "svn obliterate" command. We know what we sort of
want, but we need to know exactly how it works and what it should do in each
and every circumstance.

I have found that as long as I keep binary files out of Subversion, I really
don't need obliterate. But, developers aren't thrilled about that. They find
it easier if pre-built revisions are stored in Subversion. It's nice to be
able to pull a Jarfile out of Subversion rather than depend upon Ant/Ivy to
do it for you. Sometimes you build specific "core" jars that you simply
don't want to version via a release repository, but want to share between
projects.

There are also times when it is extremely important to completely remove a
particular revision of a file. In Financial systems, it is quite common for
a developer to check in a file and then discover that customer proprietary
data was included. Because of this, I don't recommend Subversion in certain
situations.

Subversion does need an obliterate command, but it will be very difficult to
implement. By the way, when I was using Perforce at one site, I think I used
the obliterate command maybe about a half dozen times in the two years I was
there. Most of that time, it was a developer who accidentally checked in the
wrong version of a file. In Subversion, you'd simply tell them to check in
the correct revision. (Because of my experience with Subversion, we didn't
store releases in Perforce, so most of what we stored were just text files.
Therefore, we didn't have to purge our repository from obsolete releases).

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396053
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].