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

Re: svn commit: r12241 - trunk/notes/locking

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-12-10 19:29:03 CET

On Dec 10, 2004, at 12:16 PM, Peter N. Lundblad wrote:
> Since the client will never set an expiration date and the lock
> information will only be stored for locks created using the current
> working copy, what's the point in storing an expiration time that will
> never be there?

So if I ask my client to tell me about some lock in the repository,
it's going to deliberately hide that one svn_lock_t field from me?
Where does this hiding happen? Does the server not send everything?
Does the ra_svn/ra_dav library hide something? Or does libsvn_client
just not print that one field in svn_lock_t?

Similarly, if I have a locktoken in my wc, I would expect the whole
svn_lock_t to be cached in .svn/ as well. Or do we only cache *most*
of it?

I guess I feel that the client will definitely be manipulating
svn_lock_t objects, and so it seems like "extra work" for .svn/entries
to deliberately store only 'some' of the fields, or for various layers
to worry about screening things out. It seems like we're creating
extra complication for no reason.

"Why so difficult?"

An svn_lock_t is a transparent object meant to be used on both sides of
the network, cached in the client, displayed by the client, presented
to users. I so no reason to create extra complexity to hide a field,
just because the user can't change it. The user can't change
lock->creation_date either, right?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 10 19:39:13 2004

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.