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


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.