[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: what proofs look like

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-10 18:06:49 CEST

Indeed, I'm glad Tom can find time to write detailed proofs of his work.
Unfortunately, the main theory nuts on Subversion seem to be busy enough
with their real life job, or school work to come up with detailed
specifications of the operations that Subversion is attempting to solve.

I'm also glad that Tom could find the time to clarify the generic tree
patching concepts that he did, because while most of what his proof
described is fairly self-evident to me, having an actual proof is also
just a nice thing to have, because it gives your gut instincts about
problem spaces a more secure foundation.

In terms of the patch mechanics:
While the patch semantics make sense (barring the non-handling of
copies), existing working copy libraries of various source control
systems aren't really setup to handle the fully generic patch in one
distinct target system checkin.

e.g.: Subversion's working copy model just isn't setup to handle
arbitrary chained working copy operations.

This is mostly because there just hasn't been nearly as much focus on
improving this part of the system.

Honestly, I don't think the biggest problem folks will have with tree
merging/patching will be renames/copies. I think the biggest problem
folks will have is getting a given set of changes into this patch

i.e. the typical vendor branch update problem into your local


Do you want a dangerous fugitive staying in your flat?
Well, don't upset him and he'll be a nice fugitive staying in your flat.
> -----Original Message-----
> From: Greg Hudson [mailto:ghudson@MIT.EDU]
> Sent: Friday, August 09, 2002 11:20 PM
> To: dev@subversion.tigris.org
> Cc: Tom Lord
> Subject: Re: what proofs look like
> (Recipients and subject line trimmed.)
> For those who are curious, what Tom proved here is that, given a tree
> delta and an original tree, you can reproduce the modified tree.  Or
> can reproduce the original tree from the modified tree and the tree
> delta.  For this to work, a tree delta has to include information
> files which have been added, removed, or moved (arch's model of the
> world doesn't seem to track copies, just moves), but you don't have to
> include information about files which just sat there--except for
> to their contents, of course.
> I have no particular insight on how these formalisms are related to
> Tom finds us ridiculous to try to work with, or why we only work on
> "open source" in quotes.
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 10 18:07:34 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.