kfogel@collab.net wrote:
> 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.
I'm not entirely sure whether this is a bright idea, but it may solve
the problem of storage and disconnected operation:
As Greg Hudson mentioned, autoprops are simple (<key>, <value>) lists
already, and AFAICS treated as apr_hashes in the client. What issues
would be introduced if the server itself was solely responsible for
storing and applying the autoprops during a commit operation?
In that scheme, the Subversion client need not be modified to support
server-side autoprops, and backwards compatibility with older clients is
maintained by default. The actual list of autoprops could be stored as
an svn_hash somewhere in the repository directory, and possibly edited
via the svnadmin tool.
Thinking over this, after a commit WCs could be in an inconsistent state
as the WC props for a given file may not reflect the state on the
server, since the server added extra props that the client did not send.
I don't understand enough about Subversions internals to know if this is
a problem.
Another problem with this scheme would be how it interacts with older
client accesses via file:// schemes. Actually, I'll stop attempting to
contribute there.. This is too complex a problem for my rookie knowledge. ;)
Just some thoughts for the fire,
David.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 29 01:35:14 2005