Re: [viewvc-dev] svn commit: r2626 - branches/property-diff: lib templates
"C. Michael Pilato" <[email protected]> Mon, 17 Oct 2011 13:02:35 -0400
| Newsgroups | gmane.comp.version-control.cvs.viewcvs.devel |
|---|---|
| Organization | CollabNet, Inc. |
| Message-ID | <[email protected]> |
On 10/17/2011 12:44 PM, Alexey Neyman wrote: > On Monday, October 17, 2011 08:37:21 am C. Michael Pilato wrote: >> Hrm... we might want to think through this one a bit. Will this same URL >> format grow into a fully recursive directory diff in the future? Do we >> anticipate the need for specifying the depth of a directory diff >> (recursive/non-recursive, depth-zero/depth-infinity, etc.)? > > Yes, I thought "&recursive=1" would be selecting the recursive diff, and the > link would look like: > > Diff to previous 1234 (recursive) > > Where "previous 1234" links to a diff of the directory itself (as it does now) > and "recursive" links to the, eh, recursive diff. What do you think is more intuitive, that a directory diff URL without a recursive-ness specifier included would be recursive, or that it would be non-recursive? I kinda think that recursive operation should be the default, especially since Subversion is unique in that it offers some non-trivial meaning to the phrase "non-recursive directory diff" (because it actually has something to diff in such scenarios: properties). > I don't think depth specification for diff would have much use. It is very > useful for sparse check-outs, but for diffs? I don't think so. Yeah, agreed, this is squarely in boolean territory. -- C. Michael Pilato <[email protected]> CollabNet <> www.collab.net <> Distributed Development On Demand ------------------------------------------------------ http://viewvc.tigris.org/ds/viewMessage.do?dsForumId=4251&dsMessageId=2857810 To unsubscribe from this discussion, e-mail: [[email protected]].
signature.asc
(application/pgp-signature, 198 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk6cX6sACgkQokEGqRcG/W6TXQCdHlsarwBNqxenzsMVZqkvxkLu q3IAnRINlfyUrLZk9yvh1EnTvdaV/xO7 =n2nY -----END PGP SIGNATURE-----