I vote for an obliterate command, but we are talking about two separate
commands "obliterate" and "remove version (rmver)":
* I've been a CM admin for about 15 years, and I find that a user will
request me to obliterate a file about 3 or 4 times per year. Mostly with new
files that were accidentally added and contained sensitive information. I've
never "obliterated" files with substantial histories, and I'd probably
refuse if a user request that I do -- especially if it involves stuff that
was released (either internally or externally).
* I find "rmver" a bit more useful. In ClearCase, developers don't develop
off of the head of the trunk (called /main in ClearCase). Instead, they
create a branch and do their development work on that branch. Once they've
determined that their code works and it is stable, they would merge their
work onto the head of the trunk. (In ClearCase, the trunk was suppose to be
always stable and releasable)
If you look at a version tree of a file, you'll see dozens of branches
merging in and out of the /main branch. To clean up this mess, many places
have a policy of removing "dead" development branches and versions. You
still have most of the versioning information since you're not deleting
anything off of the main trunk. You're only deleting old versions that even
the developers no longer care about. This speeds up many of the scripts we
use (image how long the "blame" command would take if you have a file with
20 versions on the main trunk, and hundreds of versions on a dozen different
side branches) and speeds ClearCase up a bit too. However, it doesn't save
very much room since you're only storing the deltas.
* It is extremely common -- despite what people may claim "best practice"
states -- to put binaries of compiled programs in your archive. This gives
you a single place where developers can get precompiled libraries to develop
against, it gives everyone a single location of a guaranteed to be valid
release, and you know that the System Admins are backing this up on a daily
basis.
The problem is that binaries take up a ton of room. If you're building every
single day, and each build contains 10 to 20 gigabytes of binary data,
you'll fill up a network disk area no matter how big it is. We are
constantly removing old versions of libraries and executables that were
never released. Our policy was to remove all binaries from any "bad build",
anything from a "good build" over two weeks old, and keep any binaries from
an actual release until those binaries are no longer supported.
I would like both versions of the "obliterate" command (obliterate and
rmversion), but then I'd also like a million dollars and a pony. The
"obliterate obliterate" command might be easy to implement if we simply put
on restrictions of what it can obliterate. Maybe a file that has only one
version of itself, is not on any branches or labels, and is still in the
HEAD of the trunk. Maybe something that is in no more than "X" versions of
the archive where "X" is a fairly small number. If you make a booboo and
accidentally put in a file that shouldn't be in the archive, you can ask the
CM to obliterate it, but you better ask pretty quick. Even with those
restrictions, it would cover about 98% of the need for obliterate.
The "rmversion obliterate" command is much, much harder to implement for
reasons I outlined before. You are going to have side effects, and must
determine how you handle those side effects before you even dream about
coding. In ClearCase, we could not (at least easily) remove a version of a
file that had a branch coming out of it, or had a label on it or was
"interesting" in any other way.
But then, ClearCase versioned files and not the entire archive, so doing a
"rmversion" had limited side effects. And, these side effects were well
understood. In Subversion, where the whole archive is versioned, the effects
are much larger and more unpredictable. For example, how could I make sure I
am not accidentally removing an "interesting" version of a file? That is, a
version of the file with a tag/label on it or a file that is at the root of
a branch. In ClearCase, we would prune dead branches and remove all of those
versions. But, we didn't want to remove versions of file with labels (tags)
on them or files that are used for work that is being actively developed.
In Subversion, there is no difference between a branch and a tag except for
what exists in between the ears of the CM. How can we make sure Subversion
knows that a particular version of the file we want to remove isn't
"interesting"?
Right now, I am going to discourage my company from versioning binary files.
We will store binaries on a share and just hope that the SysAdmin is backing
up those areas on a daily basis. As long as we are only storing deltable
files, disk space won't be a major problem.
Received on Tue Apr 19 00:03:05 2005