Kudos to svn for what it is. (was Re: general replies, last in thread?)

Greg Stein writes:

> Our choices are not the same as yours. Leave it at that.

This whole conversation seems to be happening absent a
clear reminder of Subversion's goals and the laudable
degree to which the team has pursued them. This project
is an effort to develop a compelling replacement for
CVS. Everything else is out of scope.

It's not easy to keep a true focus. The svn team deserves
a pat on the back for the discipline to stay on task.

Every now and then, somebody comes along and wants to compare
their SCM tool to see which is bigger.

Wouldn't it be more appropriate to just suggest that Tom Lord
go have a nice argument with Larry McVoy? ;-)

--
Eric W. Sink
eric@sourcegear.com
http://www.ericsink.com/
----- Original Message -----
From: "Greg Stein" <gstein@lyra.org>
To: "Tom Lord" <lord@regexps.com>
Cc: <dev@subversion.tigris.org>
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: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org