Re: patchsets

> Simplying saying "I've solved this problem" is not constructive.

Really -- I assumed you were more familiar with arch.

Ok then, here's a whirlwind tour of the abstract solution:

1) There's a global, territorial, referentially transparent namespace
   for project trees.

2) There's a standard for describing any project tree in terms of a
   source to source transformation derived from the definitions of
   earlier revisions.

   In the simplest case, the "source to source" transformation is
   a patch set against a single base revision, but arbitrarilly more
   diverse/complicated transformations are potentially valuable (e.g.,
   a way to say that revision B is derived from its base revision by
   renaming a particular identifier).

   Because of this standard, you can regard globally named revisions
   in terms of their heritage: a base revision plus a series of
   source->source transforms, resulting in the named revision.

3) There's a standard for recording, in each project tree, the
   change-set heritage of that project tree.

   This is used for intelligent merging and auditing generally.

4) There's an open-ended set of protocols for accessing and
   propogating the database of named revisions.

   Any protocol that can be disguised as a small subset of FTP
   can be made a transport mechanism for distributed change set
   mgt.

4) There's an open-ended collection of tools for merging sets of
   changes intelligently (e.g., avoiding redudant application of
   non-idempotent transformations).

   `star-merge' is a quintesential example.

Because the namespace mapping is territorial, different parts of the
namespace can be maintained by independent players, using independent
repositories and divergent repository technology.

The abstract model doesn't much depend on how the named revisions are
stored. Because of referential transparency, they can be replicated
freely (for example); or they can be stored in either an FTP dir or a
svn repository.

-t

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 15 03:26:44 2002