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

Re: Repository-defined autoprops.

From: steveking <steveking_at_gmx.ch>
Date: 2005-05-27 22:28:51 CEST

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.
> 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, ...)


   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

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.