> Full distributed repository functionality is a bit more than
> changesets.
No kidding. :-)
> The important thing is to be able to refer to a group of
> checkins by a single name.
Sure. You might want to define a global namespace for these entities
-- perhaps one that is independent of any particular rev
ctl. software. Such a namespace has many applications for rev ctl and
well beyond: for example, in release engineering tools and testing
tools.
Distribution is more than just the namespace, though. For example,
recording repository-independent merge history is an issue. So too
are intelligent merge operators.
I attempted to ask nicely for the svn developers to work on portable
whole-tree patch formats and I'll reiterate that request. That issue
leads to several others (e.g. the "tree inventory problem") that you
really ought to consider before a 1.0 and/or massive deployment. I
believe that facing these issues can, among other benefits, help clean
up some of the "corner cases" that you seem a bit squirrely on.
I think a big current challenge in revision control technology is to
build a distributed library in which to catalog _all_ commercially
significant free software development activity in a form that's useful
for advancing the engineering practices that creat, maintain, and
deploy that software. Distribution and avoiding rev ctl. package
lock-in are critical considerations.
What is breath for, if not to waste it, now and again....
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 02:40:02 2002