[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-12-10 22:15:27 CET

On Fri, 10 Dec 2004, Ben Collins-Sussman wrote:

>
> On Dec 10, 2004, at 12:29 PM, Ben Collins-Sussman wrote:
> >
> > 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?
> >
>
> I guess what worries me is that 'svn info foo.c' and 'svn info URL'
> might show different fields to describe a lock. In my idealistic
> world, 'svn info' would always print the entire svn_lock_t. But that
> would mean caching extra -- essentially useless -- information in
> .svn/entries, such as the expiration_date and absolute_fs_path.
>
Re expiration_date: give me a scenario where that will end up in the
working copy. That might clarify somewhat.

Re the absolute path. Is there really a point in showing it? When will it
be something other than the absolute path of the locked item?

> So which is better or worse? Does it matter that 'svn info' always
> show the same svn_lock_t fields, regardless of local vs. remote
> operation?
>
They should print the same info as far as possible. But if you look at the
info command as a whole, it will have to print different information
depending whether the information comes from the WC and the repsitory. For
example, there is no schedule in the repo.

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 22:15:54 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.