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.
Autoprops are properties that get automatically set on a file when it
is added or imported. (Thus, the only operations under discussion in
this mail are 'add' and 'import'.) Each client defines its autoprop
mapping independently, even if it's the same mapping used by all the
other clients talking to a given repository. The repository has no
way to broadcast autoprops; it all happens client-side.
A client specifies autoprops by setting 'enable-auto-props=yes' in the
'[miscellany]' section of ~/.subversion/config. This makes Subversion
pay attention to the '[autoprops]' section of the same file. In that
section, each line is of the form "PATTERN = PROPNAME=PROPVALUE",
where PATTERN is a file-globbing pattern, and PROPNAME and PROPVALUE
are what you think they are. If a file matches multiple PATTERNS,
it's random which one gets used -- the order in the config file does
not matter. (I suspect this is because they get hashed internally?)
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.
Also note that we currently cannot have multiline property values.
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.
Q: Is autoprops for directory paths important?
A: No, I don't think so (but I'm not positive about that).
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.
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 just started to write up a non-iprop solution, and then erased it
after realizing the complexity of this problem.
So I guess I'll just post this now and at least see if we generally
agree on the problem & solution space. If anyone has any bright ideas
for how to do autoprops right, please post.
Confidential to Brane in Ljubljana: I now have a retroactive
motivation for why I started the log message template discussion first
(aside from the fact that it's more important to CollabNet, which I
certainly don't want to hide). It's that log message templates are a
simpler problem, and therefore lower-hanging fruit, because we don't
really need to support disconnected operation (which we've discussed
in another thread, so I won't repeat why here).
-Karl
---------------------------------------------------------------------
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:02:03 2005