[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: patchsets

From: Zack Weinberg <zack_at_codesourcery.com>
Date: 2002-10-16 00:58:35 CEST

On Mon, Oct 14, 2002 at 08:23:56PM -0700, Tom Lord wrote:
> > But you still have to remember to do it. I think a system genuinely
> > tailored for patchset maintenance would prevent the user from even
> > having to think about rip-driver-and-VM unless there was a conflict
> > between them.
>
> That get's into workflow-based client UIs. I agree that that's the
> future and implies reconceptualizing svn as a storage manger, freezing
> and, if anything, simplifying the existing interface, and starting to
> think of layers on top of that.

Buried in this is a key reason why no one is listening to you.

Everyone participating in the development of Subversion is deeply
familiar with the inadequacies of CVS. Many of these are trackable
directly to the fact that CVS is a layer on top of RCS, and therefore
cannot do anything that cannot be represented in RCS ,v files:
renames, atomic multi-file change sets, and merge arrows being my
personal top three.

Your suggestion that everything above and beyond what is implemented
now at the storage level, be pushed into higher layers, is basically
equivalent to suggesting that we go back to a design that we already
know does not work.

Now I'm very much interested in seeing some of arch's features make it
into Subversion. But I want to see them done right - as fully
integrated components of the database, not as a tottering tower of
layers. And I don't mind waiting for 2.0.

zw

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 16 00:59:18 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.