Sorry to follow up to myself but just a couple quick amplifications:
With that repository layout, it's a small-matter-of-scripting to
(a) build a bidirectional gateway between svn and arch (which
means the ability to exchange changes between distributed
repositories in controlled ways);
Arch already supports WebDAV transport for it's core data. A gateway
such as this would mostly mean being able to fetch the changesets and
log messages associated with a particular "patch-N". If those files
are in the svn repository, that's utterly trivial -- if they aren't,
it's a matter of either batch-computing and memoizing them, or
computing them on command with caching. In any of the three
scenarios, this is a small amount of scripting, with most of the
"magic" taking place client-side in the form of layered-over-svn-cli
interface tools that understand the naming conventions.
While "patch-N" isn't final, users can edit it in the usual
svn manner. So, instead of a single user creating "patch-N"
-- the new thing here is that you could have a team working on
"patch-N" in the CVS style.
(Just trying to create a big rosetta stone:) the project management
style I'm thinking of there uses the "patch-N" labels as a kind of
"mini-milestone" -- those milestone markers serving to define the
units of "logical changesets" -- for review and exchange.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 20:49:35 2003