> From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
> Tom, maybe I'm dense or blind or something, but could you point
> me at a design doc for what you're proposing?
Pretty much. It depends on how much detail you are willing to dig
into. I can give you design-revealing documentation and what would be
regarded from the svn perspective as a functioning prototype.
If you're serious, and interested in details, let me start by
suggesting you grab a copy of the arch source code from
http://regexps.srparish.net/src/arch/
because I'm going to point you to some docs in the source tree.
(That's also the "functioning prototype".)
From the svn perspective, you need to understand that arch is not a
monolith. It's a bunch of variously orthogonal and strictly layered
components, each simple. The docs don't always make that clear
because they're written for people using arch as a whole.
In arch terminology, some of those components are things like the
global namespace of revisions, the changeset format, and the project
tree format (which includes patch-logs, where merge history is
stored). Those three components are enough to define what various
merging operations do (as well of much of what is needed for
distributed branching) -- and they're perfectly portable to svn.
Another arch component is the "archive design" -- how an arch
repository is stored in an ordinary file system. This component in
particular is the one of least immediate relevence to svn, because the
role of this component would be taken over by a svn repository.
That's roughly what I'm proposing: a reimplimentation of arch
(tractable because its small, necessary because svn wants to run on
windows) -- but able to use svn as a storage manager. And as part of
that effort, making any necessary design tweaks to arch to make it run
smoothly in the context svn, and well in combination with conventional
svn usage patterns.
So, docs:
Well, gosh. Where to (efficiently) start?
It might be helpful to at least skim the arch tutorial, for an
informal overview and vocaburlary. In the source tree, that's in the
top level `docs' directory, and on the web, at:
http://regexps.srparish.net/tutorial/arch.html
and there is more detailed reference documentation in the source tree
at "src/arch/manual/=retired" -- the file arch.doc being a table of
contents, and grep can help you line up chapter titles with the .doc
files that describe them.
I'm proposing that arch project trees, which currently include the
merge history in project logs in the controversially-named top-level
directory "{arch}", be stored in svn -- using a convention of svn path
names to map those revisions to the arch global namespace of
revisions. The svn user experience would be somewhat analogous to
the "checkin/commit" paradigm of BK: "checkin" (the current svn
commit) to use CVS-style, with "commit" (renamed something else in
svn, like "publish") to turn a group of earlier checkins into a
changeset revision. Then fancy merging and distribution in terms of
the changeset revisions.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 11 01:28:17 2003