kfogel@collab.net wrote:
> This mail is about propagating repository-defined autoprops to
> clients, a feature we don't have, but wish we did.
>
> The Current Situation:
> ======================
>
> Subversion's autoprop support is documented at:
>
> http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-2.4
>
> For convenience, I will summarize it here.
[snip]
> As far as I can tell, autoprops work only on files, not on
> directories. In typical use, this probably doesn't matter, since
> people mostly use it for mime-types, eol-styles, and keywords.
Yes, they only work on files (at least, last time I checked). That's the
reason why svn:ignore can't be used with autoprops.
> Also note that we currently cannot have multiline property values.
Would also be a problem for svn:ignore.
> Problems:
> =========
>
> This design makes it difficult for a repository (or a project) to
> specify autoprop policy. The admin has to notify all users what the
> autoprops should be, out-of-band, and the users have to manually make
> the right adjustments to their ~/.subversion/config files. If the
> policy is updated later, there is no automated way to transmit the
> update. The admin has to send out another email, and everyone has to
> make the adjustments manually again.
>
> What Should A Solution Look Like?:
> ==================================
>
> Before we can design a solution (and especially, before we can know
> whether it might share any mechanism with log message templates), we
> need to know what we want.
>
> Q: Is disconnected operation important?
>
> A: Yes, because 'svn add' is one of the actions.
>
> Q: Is operation in the absence of a working copy important?
>
> A: Yes, because 'svn import' is one of the actions.
IMHO this isn't important. Usually, you use import when you start a
project. Once you've imported all the files, you then start setting up
policies (or am I completely wrong here?).
> Q: Is autoprops for directory paths important?
>
> A: No, I don't think so (but I'm not positive about that).
I think that one is important. At least, if this not only has to work
for the above mentioned Subversion properties. TSVN for example uses
properties on folders as a replacement for certain server dictated settings.
> Q: Is it enough to specify autoprops per-repository, or do they need
> to be per-project, which in Subversion means per-directory?
>
> A: I think per-directory is significantly better.
>
> I didn't always think this. At first I thought per-repository
> would be good enough. After all, the most common use cases are
> svn:mime-type, svn:eol-style, and svn:keywords. I would think
> that these three properties rarely need different mapping rules
> for different projects in the same repository. Well, different
> projects might have different policies about svn:keywords, but
> probably not for svn:mime-type or svn:eol-style.
>
> But anyway, projects may have other properties (not even
> necessarily "svn:foo" properties) that they need to map.
> Although I can't come up with a concrete example right now of
> when different projects might need incompatible mappings, still,
> this "feels like" a plausible use case. This is also why I'm
> not sure whether directory support is important.
If you look at the properties TSVN already has defined to use as project
settings, I think per-directory would be great.
> So there you have it. We want:
>
> * Disconnected operation with a working copy.
>
> * Connected operation without a working copy.
>
> * Per-directory instead of just per-repository (maybe -- I at least
> am not sure about this).
>
> * It's an open question whether mapping directoryglobs<->props is
> important. Right now my guess is it's not.
>
> This might be a tall order.
>
> Frankly, the only good solutions that come to mind involve inherited
> properties. I don't, however, have a good specification for how
> inherited properties should behave, nor how to implement them.
I don't know how this would be implemented, but this is what I think
inherited properties should behave:
- props get inherited from the directory tree downwards (parent to children)
- if a child dir/file has the same property set as the parent, the child
has priority (this so that subprojects can override the settings of
parent projects, i.e. define their own props/rules/settings)
- if a child has the same property set, but the first line of it's value
is e.g. '*', the childs props don't overwrite the parent props but add
to them (useful for svn:ignore, svn:mime-type, ...)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 27 22:31:02 2005