[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: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-12-10 20:00:19 CET

Ben Collins-Sussman <sussman@collab.net> wrote on 12/10/2004 01:53:16 PM:

>
> 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.
>
> 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?
>

If the value will always be the same in a WC, why couldn't svn info just
"pretend" it has the info and output what it would have said had the info
been present?

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 10 20:01:52 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.