Greg Hudson <ghudson@MIT.EDU> writes:
> On Tue, 2005-11-08 at 22:07 -0600, kfogel@collab.net wrote:
> > When you commit, the client contacts the server with a new RA call,
> > propget_walking_upward().
>
> I think some perspective is in order here. Right now we have a number
> of present and future features which involve settings with the following
> qualities:
>
> * They might vary between directories in a repository.
> * Most of the time, they don't vary between lots of directories.
>
> These features include:
>
> * (Present) svn:ignore
> * (Future) Repository-specified auto-props
> * (Future) Log message templates
> * (Future) Easy branch comparisons
If "Easy branch comparisons" is what I think it is, Jim had a terrific
idea about how to do that. I won't describe it here, but maybe this
comment will spur him to do so :-).
> (Log message templates have the added issue that it's ambiguous what to
> do when you have a commit across multiple directories with different
> templates. But that's just a matter of choosing semantics, and is
> mostly irrelevant.)
>
> Arguably, we haven't implemented any of the future features *because* of
> the clunkiness of directory properties which mostly don't vary between
> lots of directories. It's very tempting to try to solve this clunkiness
> in a feature-specific way, because it lets you get the feature done
> without having to solve anything hard. But I think that would be a
> mistake; even if our eventual iprops mechanism winds up being a little
> ugly and having some corner cases which are hard to get right,
> Subversion will be more elegant overall if we don't take a narrow view
> of the problem.
>
> However, to solve the general problem, we need a solution which works
> offling. We can punt on offline log message templates, but we can't
> really punt on offline ignores values or (probably) auto-props or ttb
> values.
Is this a case of the perfect becoming the enemy of the good? (It's
not a rhetorical question -- I'm really not sure myself.)
One aspect of this log message template proposal is that if we one day
grow inherited properties, it Still Just Works. If you walk up parent
dirs in the presence of inherited properties, you'll just get your
answer sooner. Nothing breaks. Newer clients would know to look
locally for the property, of course.
So I don't think the proposal in any way *obstructs* doing inherited
properties in the future. It would mean continuing to support some
legacy code after we get inherited properties, but not a whole lot:
only the server side code, which is small, would need to be kept (for
compatibility with old clients). On the client side, the old code
just disappears. That's not too shabby a deal.
This part doesn't (yet) convince me:
> But I think that would be a mistake; even if our eventual iprops
> mechanism winds up being a little ugly and having some corner
> cases which are hard to get right, Subversion will be more
> elegant overall if we don't take a narrow view of the problem.
That's only true depending on just *how* ugly and corner-cased it is.
So far, all the proposals we had were, IMHO, too ugly and unrobust to
consider implementing. I did toy a while with your proposal, at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=100409,
and came to the same conclusion. If that proposal is still in play, I
could go into more detail about why.
If we can think of a robust way to implement inherited properties, I'm
all for solving log message templates and everything else that way.
But is such a solution really available? (An existence proof would be
best :-). )
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 9 07:33:37 2005