Re: Design doc questions

[Karl Fogel <kf...@galois.collab.net>]

Bill Tutt <bi...@microsoft.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
now. :-)

> 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

> Destroy\Obliterate:
> 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
> differencing.
> 
> 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. :-)

Re: Design doc questions

["Jonathan S. Shapiro" <sh...@eros-os.org>]

> Data destruction is always possible to add later. :-)

The problem is selectivity... :-)