[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: David Wilson <dw_at_botanicus.net>
Date: 2005-05-29 01:35:01 CEST

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,


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

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.