Bill Tutt <email@example.com> writes:
> I was looking through the design doc, and a few questions entered my mind.
The design doc is pretty old; better off reading header files right
> VDelta: How would you compare and contrast vdelta vs. xdelta of PRCS fame?
> It might be useful to spend a paragraph comparing it, or if one of the
> vdelta docs makes the comparison, then mentiong that would also be cool.
vdelta docs do this comparison
> I didn't notice anything in the design document touching on completely
> removing things from the Subversion store. What are your thoughts about this
> feature? I know that this feature runs contrary to conventional source code
> control methodlogy, but sometimes pragmatism has to win out.
> Typical reasons for destroying data (or portions of it):
> * Screwing up a branch operation. (I must admit to forgetting how CVS
> cares about differentiating between branching and tagging) I tend to do this
> every so often in VSS.
> * Disk space issues:
> There are different approaches to handle this kettle of
> fish. Here are some I've seen discussed or done elsewhere.
> * Allowing an Archive operation that bundles up all changes before a
> certain version of the repository, exports it into some format, and then
> removes the info from the existing repository. There's no reason this
> archive could cover just a portion of the repository as well.
> * Allowing to remove certain revisions of binary files. I'm not sure
> if this is as useful for a system that actually supports a binary
> differencing algorithm. It is useful for systems that don't support binary
> I thought I might as well add the coolest feature I've ever seen in a client
> side source control tool: WinCVS's revision history graph.
Data destruction is always possible to add later. :-)
Received on Sat Oct 21 14:36:06 2006