Good points. The more I think about this the more I feel that a "prune"
command is really the best compromise. Something like:
svnadmin prune REPOPATH -r REV PATH ...
Prunes the specified path(s) starting at the specified revision from the
specified repository. Each path (file or directory) is obliterated from
the specified revision, and all subsequent revisions, including all
branches made at or after the specified revision. The change is
permanent. Pruning at the revision where the file was originally added
to the repository will obliterate all traces of the file. Pruning at a
branch revision will obliterate all traces of the file on that branch.
My gut feeling is that this will accomodate 80% of users needs but keep
the model simple enough so that it can actually be used without leading
to disasters.
I've also seen lots of shops where entrie build toolchains are
checked-in. The rationale here is usually broken, and consists of either
(a) over-loading the SCC system as a backup system or (b) a fabled "we
need to be able to reconstruct our build environment". Of course, in the
latter case, you need more than just the toolchain (think OS etc etc.).
Incidentally (OT), I now use virtual machines as a way to maintain build
environments. Just ZIP the whole thing up and put on optical media --
VM, OS, tools, etc etc.
--Tim
Weintraub, David wrote:
> 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:41:08 2005