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

Re: RFC: Log Message Templates via new hook.

From: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2005-05-20 19:01:37 CEST

On Fri, 2005-05-20 at 12:43 -0400, Greg Hudson wrote:
> On Fri, 2005-05-20 at 10:31 -0500, Brian W. Fitzpatrick wrote:
> > Agreed. However, I think that if we want to do inherited properties
> > right we're going to have to look long and hard at how important it is
> > to support detachable directories in working copies. This seems to the
> > be a wc feature that some folks are unwilling to sacrifice, but it also
> > seems to the biggest obstacle to doing inherited properties in a non-
> > kludgey manner.
> We can get all the usage benefits of inherited properties without
> sacrificing severability; it just means we get none of the performance
> benefits on the client side.

Thus the "kludgey manner" I was referring to.

> I'm not sure anyone is wedded to working copy severability, but I
> suspect there are several of us (certainly, myself included) who would
> consider it very poor form to drop that feature during 1.x.

I'm not advocating that we drop severability. I am, however, willing to
entertain the thought of inheritable properties only working in non-
severed working copies (but the more I think about this, the less
elegant it looks. *sigh*)

> We could virtualize the working copy library and design a new working
> copy format which isn't severable, to be used optionally at checkout
> time, but that's an even more major undertaking than inheritable
> properties since there are a bunch of other improvements we'd want to
> design in at the same time. Also, if we virtualize the working copy
> library we have to figure out how we will detect what kind of working
> copy we're operating on when a user does something like "svn update".
> And we'd be constrained to the current libsvn_wc API, which may be
> simply too constraining.

Egads, I don't want to go there.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 20 19:00:45 2005

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.