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

[Madan U Sreenivasan <ma...@collab.net>]

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

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

[kf...@collab.net]

Madan U Sreenivasan <ma...@collab.net> writes:
> 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. 

I'm a newcomer to this discussion, but I think Madan has a point:

If we're fetching meta-information about dirents, we might as well
fetch everything.  Adding the extra bytes on the wire is not costly
(it's "meta-information", not "information" :-) ), certainly far less
costly than extra round trips to fetch it later.  Any consumer is free
to ignore whatever bits of meta-information it doesn't want, but we
might as well just hand it everything up front.

Remember the X Windows libraries, back in the good old days?  Every
function took a bitmask, to tell it what information the caller wanted
back, so that the X server could carefully leave out unwanted
information, thus reducing the number of bytes -- but not the number
of round trips --between client and server.  Let me put it this way:
there's a reason no one designs APIs that way anymore :-).

This general philosophical note has been brought to you by:

-The Letter Q, and
-Karl Fogel

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org