Tom Lord <lord@regexps.com> writes:
> Change sets are especially useful for communicating between
> organizations who can not, in general, be presumed to use the same
> revision control system in-house.
>
> In other words, merge histories for change-based management need to be
> distributed and storage-manager independent. I've found that it
> works out nicely to store this information in regular text files,
> within project trees themselves.
kfogel:
Yeah, that's what I was thinking too.
Well, all the more reason to consider using a svn binding for arch.
arch already has that feature.
There _are_ open design issues -- but they are quite tractable if we
can get moving on them.
> You _might_ also want to have change history meta-data in svn
> repositories to help with merging that is internal to a single
> repository -- but don't confuse that with the more general,
> inter-organizational kind of merging.
It would be better to not distinguish between the two kinds of
merging, if we can avoid it; or treat them the same, just that the
"internal" merge might have more data available to it (but in the same
format as usual).
Sure. Good. Align features to display consonance and avoid premature
optimization. Almost sounds like the beginnings of a plan. :-)
This is, BTW, another reason to freeze the client earlier than you
might have wanted to and factor out UI work to separate projects.
It's a big confusing mess trying to figure out what happens when you
mix CVS-like file-at-a-time commits with changesets (you noted some of
the issues in your example). My `svn publish/retrieve' hack avoids
the issue (by imposing "manual management" of the bridge between the
two paradigms), but I tend to think future UIs are going to look a lot
different from both the current arch UI, and the current svn UI. Both
of the latter two will wind up being low-level, internal interfaces.
-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 21:32:01 2002