On Mon, 2002-10-14 at 21:28, Tom Lord wrote:
> 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.
> 3) There's a standard for recording, in each project tree, the
> change-set heritage of that project tree.
> 4) There's an open-ended set of protocols for accessing and
> propogating the database of named revisions.
> 4) There's an open-ended collection of tools for merging sets of
> changes intelligently (e.g., avoiding redudant application of
> non-idempotent transformations).
That's a description of arch, not a description of how to apply arch to
the problem I described. (In
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=23241
in case context has been lost.) If I, a single developer, have work to
do on many interdependent patch sets, then the problem is not a need for
global naming, or a need to avoid redundant merges, or a formalized way
to propagate changes between repositories. And Subversion already has
change sets. The needs are a way of modeling the interpendencies of the
patches (which can form a dag, not just a tree), and a way of generating
diffs for each patch set without having to manually maintain a branch
representing the join of the patch sets it depends on.
The solution may be scripts or hooks on top of a simple revision control
system (like CVS or Subversion), but I don't think they're trivial
scripts or hooks.
---------------------------------------------------------------------
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:39:12 2002