You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2002/02/06 08:34:44 UTC
Re: general replies, last in thread?
On Wed, Feb 06, 2002 at 02:05:04AM -0800, Tom Lord wrote:
>...
> * What's a Revision Library?
>...
> quickly, etc. While, officially, I hate to admit it -- I'd bet that
> revision libraries are a feature that could be easily added to
> Subversion.
Yes, it sounds like it could be done. With a bit of scripting, I could
probably create a Python script that generate a (SVN-based) revision
library.
But until that happens, you get to claim the feature :-)
>...
> * Isn't Zack really neurotic about shell scripts?
hehe... It is certainly an interesting approach, and (empirically) can do
the job; I don't have any direct/immediate problem with it. 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.
(there are obviously problem spaces where scripting arch is quite
appropriate, but (IMO) things like GUIs would generally want linkage)
>...
> * What do you *really* think, Tom?
>
> 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 starts from clear answers
> to those questions, then asks "how do you package this into a usable
> system?"
Euh... I think we aren't worried about the semantics. That's been quite
well-defined for a while (branches are just other directories, so merging is
just applying diffs from those paths against the working copy). We're
working through the implementation and code (re)factoring.
> Another problem is the whole question of mixed working directories.
> That goal follows from trying to emulate the CVS user interface, and
Nah. It is an artifact of central repositories. With a local repository, you
can assemble bits from multiple repositories. With central repo's, you
assemble a working copy from multiple repo's.
Cheers,
-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
Re: general replies, last in thread?
Posted by Tom Lord <lo...@regexps.com>.
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.
Saying you have the right (or nearly right) primitives isn't a slam --
it's a compliment. I didn't say your design choices were "primitive"
-- I said "SVN has a plausible set of primitive concepts (though
there's some tweaks I'd make)." Your building a layered piece of
software and I said that the design of the lower layers looks
reasonable.
But tempers seem to be flaring, so ...
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Kudos to svn for what it is. (was Re: general replies, last in thread?)
Posted by Dan Wilder <da...@ssc.com>.
On Wed, Feb 06, 2002 at 06:59:34AM -0600, Eric W. Sink wrote:
>
> 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/
May I applaud Eric's sentiment?
As a long-time CVS user and lurker on the CVS lists, I've followed
many "my tool is bigger than yours" discussions. I always felt
that one of the secrets of CVS's success was that the developers
stayed on-track and kept CVS well-focused, not as the CM tool
to end all CM tools, but as the best CM tool it could possibly
be, given its goals and constraints.
Those goals and constraints were modest, but well-targeted
on the needs of many an overworked software developer.
We responded by beating a path to CVS's door.
I believe Subversion has an exceedingly good start at emulating
these virtues which helped drive CVS's success. Please accept
my praise and encouragement, and please preserve what looks
to an outsider like a well-defined mission and good sense among
the developer community concerning the fine and all-too-often
mistaken distinction between a nice feature addition, and one that
could lead to destructive mission creep.
--
-----------------------------------------------------------------
Dan Wilder <da...@ssc.com> Technical Manager & Editor
SSC, Inc. P.O. Box 55549 Phone: 206-782-8808
Seattle, WA 98155-0549 URL http://www.linuxjournal.com/
-----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Kudos to svn for what it is. (was Re: general replies, last in thread?)
Posted by Zack Weinberg <za...@codesourcery.com>.
On Wed, Feb 06, 2002 at 06:59:34AM -0600, Eric W. Sink wrote:
>
> 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.
*In version 1.0*, the effort is to develop a compelling replacement
for CVS. Beyond that, I hope attention turns to other improvements
which are not directly related to replacing CVS. For instance, I
would like to see support for a distributed model a la arch or
bitkeeper, post 1.0.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Kudos to svn for what it is. (was Re: general replies, last in thread?)
Posted by "Eric W. Sink" <er...@sourcegear.com>.
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" <gs...@lyra.org>
To: "Tom Lord" <lo...@regexps.com>
Cc: <de...@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
Re: general replies, last in thread?
Posted by Greg Stein <gs...@lyra.org>.
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
Re: general replies, last in thread?
Posted by Tom Lord <lo...@regexps.com>.
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.
Performance? Feh -- that isn't where the bottlenecks are.
Ease of programming? Feh^2 -- large classes of bugs are avoided
by using processes; at worst it's six of one, half dozen of
another.
Really, multi-process applications are a large part of the reason
we use operating systems with processes at all.
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
kernel of very straightforward basis operations, it can be
reimplemented as C libraries, a perl app, a ruby app, a scheme app,
an ml app .. whatever. If you want to write apps which are
extensions, arch is the simpler foundation.
Euh... I think we aren't worried about the semantics. That's been quite
well-defined for a while (branches are just other directories, so merging is
just applying diffs from those paths against the working copy). We're
working through the implementation and code (re)factoring.
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.
> Sorry -- one more complaint about svn's use of WebDAV: I don't think
> WebDAV has the right semantic model for programming. Sure, it let's
> you think about revisions to documents -- but revisions to source
> trees have a lot more structure than that.
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?
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org