On Wed, Feb 06, 2002 at 04:17:43AM -0800, Tom Lord wrote:
>
> However, I believe its one serious disadvantage is integration
> with applications. To create clients, custom tools, etc, those
> programs will need to spawn arch tools and talk via a
> pipe. Obviously doable, but I prefer linking to libraries and
> staying in a single process space.
>
> 1. Why that preference? That would seem to be an unjustified
> prejudice.
Sigh. Not a prejudice, just a preference (as I stated).
>... [ comments w.r.t. my personal design preference ] ...
>...
> 2. If you insist, the arch repostiory, revision library, notifier,
> browser, and project tree structures are certainly amenable to
> single-process tools. Because arch is so small, and built around a
Sure, sure... Given a design, you can implement it however you'd like.
Turing complete languages, and all that.
>...
> That's oversimplifying the problem. The question of what diffs to
> apply to what trees to accomplish a merge is non-trivial, particularly
> in the case of branches which repeatedly merge back and forth from a
> trunk, or trunks which repeatedly synchronize.
>
> Yes, I agree that SVN has a plausible set of primitive concepts
> (though there's some tweaks I'd make) -- but looking at the
> documentation and merging plans recently posted to this list, I don't
> see a high level solution, yet.
Look. Now you're just getting annoying. First, you said:
"One problem that I perceive in the design of Subversion is that,
very late in the game, you're wondering about the semantics of
branches and merging -- by contrast, arch ..."
I said that we had a design figured out for a while now, and have been
talking about our implementation. But now you slam on our design choices
with things like "oversimplifying" and "primitive" and "don't see a high
level solution", etc.
Our choices are not the same as yours. Leave it at that.
We've chosen a simpler model of merges for our Version 1.0 release. The
basic, conceptual mechanics of our merge design have been solid for at least
a year.
(we spec'd out a lot of merge issues last year in chicago, where we also
compared/contrasted SVN against a changeset engine and its semantics)
>...
> Euh... I think you have a bit to learn about WebDAV. In particular, check
> out Workspaces, Baselines, and Activity Sets. Those concepts all deal with
> entire sets of changes, manipulating them, merging them together, etc.
>
> What of distributions? Multi-package configurations? ChangeLogs?
> Surely a revision control system browser for programmers should relate
> those pieces. Looking towards the future, what of bug database
> synchronization? It is true that I am not a WebDAV expert, but am I
> wrong in believing that it was not designed for software management,
> but rather for a less specific space of revisioned documents?
WebDAV and DeltaV are *protocols*. That's the first thing you should learn.
That said, DeltaV is about how to perform version control operations. Its
model, and the operations on that model, incorporate many aspects of
configuration management. Software is one application of that, but it covers
the whole gamut. And it *does* deal with configurations, not just single
documents. My comment re: Workspaces, Baselines, etc was specifying to point
you towards its configuration mgmt aspects.
Many of the questions you raise are at the application level, not at the
network protocol level.
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006