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

Re: [Patch] Issue #2291 - 'svn ls -v' return locking information

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2005-07-01 10:47:24 CEST

On Fri, 2005-07-01 at 01:50, Peter N. Lundblad wrote:
> On Thu, 30 Jun 2005, Ben Collins-Sussman wrote:
>
> [snip]
> Moving the lock fetching to the server would avoid the network round-trips, but isn't good
> either.
I would side with that... doesnt seem to break the natural design of the
existing code....
> Either way, we should have a way to say that we don't want the
> lock info when it isn't needed.
I beg to differ. lock is now as vital an info as the author or revision
no.( two other entities of the svn_dirent_t struct). We could compare it
with the rwx permissions of a normal unix file. I would suggest
incorporating lock info in the svn_dirent_t structure and always
returning the lock info from the server as if its just one more
attribute of the file/dir (which it is!)
I would like to place another reasoning here. Assuming, theres a new
attribute in the future - lets say compressed ( meaning the file is
stored in compressed format ... just an example ), using a
svn_ra_get_compression_info() for each dirent would simply shatter the
natural design of things. such parameters are attributes of each dirent
and IMHO should be filled in by get_dir_contents/svn_ra_get_dir (not
sure which one would be apt) by the server.
>
> Regards,
> //Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 1 10:42:04 2005

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.