[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: <kfogel_at_collab.net>
Date: 2005-07-01 16:27:01 CEST

Madan U Sreenivasan <madan@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
Received on Fri Jul 1 17:27:12 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.