Kudos to svn for what it is. (was Re: general replies, last in thread?)
From: Eric W. Sink <eric_at_sourcegear.com>
Date: 2002-02-06 13:59:34 CET
Greg Stein writes:
> Our choices are not the same as yours. Leave it at that.
This whole conversation seems to be happening absent a
It's not easy to keep a true focus. The svn team deserves
Every now and then, somebody comes along and wants to compare
Wouldn't it be more appropriate to just suggest that Tom Lord
-- Eric W. Sink firstname.lastname@example.org http://www.ericsink.com/ ----- Original Message ----- From: "Greg Stein" <email@example.com> To: "Tom Lord" <firstname.lastname@example.org> Cc: <email@example.com> Sent: Wednesday, February 06, 2002 4:51 AM Subject: Re: general replies, last in thread? > 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: firstname.lastname@example.org > For additional commands, e-mail: email@example.com > --------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.comReceived on Sat Oct 21 14:37:04 2006
This is an archived mail posted to the Subversion Dev mailing list.