On Fri, 10 Dec 2004, Ben Collins-Sussman wrote:
>
> 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?
>
I thought we wwere talking aobut the WC. Asking for a lock in the repo
will contact the server. If a lock is stored in the WC, it has to have
been created by our client. So, I don't see what information we are
hiding. We just add support for a field that will never be there.
> 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?
>
Shoudl we cache the absolute path as well? When we have the repository
root stored in the entries file,, that would be information duplication,
but before that happens we can't derive 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.
>
Check out the current client APIs. They handle svn_lock_t and return it,
but there is nothing that reads a svn_lock_t from the WC. That's because
we don't currently have the absolute path, only the lock token is required
to talk to the server, and "svn info" will have the whole entry anyway.
> "Why so difficult?"
>
If you feel strongly about storing a field that will never be there, then
let's go for it:-)
Regards,
//Peter
---------------------------------------------------------------------
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:46:30 2004