Version 5 of the patch for fixing Issue #2291.
Peter N. Lundblad wrote:
>I agree with using get_locks, but I don't think you should move it into
>the RA layer. The problem is that it will do an infinitely recursive lock
>traversal *per directory*. You can do svn_ra_get_locks in svn_client_ls
>instead. That way, you'll be able to get all locks only once.
>
>
get_locks moved to svn_client_ls2()
>When/if we get a depth parameter on svn_fs_get_locks(), we can rev the RA
>API to provide the locks as well, making it streamy (as earlier
>discussed).
>
>
Working on it :-)
>On another not, isn't it more useful to display the lock owner than the
>lock creation date with "svn ls -v". Displaying everything in the XML is
>great.
>
>
IMHO, both lock owner and lock creation date are useful piece of
information. I am still
retaining both with a simple swapping on output.
Also I am doing strcasecmp on hash keys, Will there be any protability
issues ?
>I hope to do a complete review when we've decided on the implementation.
>
>
Thanks to Peter and Sussman for their valuable comments.
Regards
-Alexander Thomas (AT)
Fix issue #2291: 'svn ls -v' should return locking information.
* subversion/include/svn_types.h
(svn_dirent2_t): New struct.
(svn_dirent_t): Deprecated and moved to group it with new struct.
* subversion/libsvn_client/ls.c
(svn_client_ls2): Gets lock information.
* subversion/clients/cmdline/ls-cmd.c
(print_dirents): Print lock information.
(print_dirents_xml): Print lock information in xml.
* subversion/clients/cmdline/main.c
Mention locking information in the help text for 'svn ls'.
* subversion/clients/cmdline/dtd/list.dtd
Updated DTD file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 23:43:50 2005