Barry Scott <barry@barrys-emacs.org> writes:
> > I actually started coding this one, but backed out for lack of time.
> > I think the idea is pretty straightforward -- add a new typedef'd enum
> > svn_depth_t with values svn_depth_zero, svn_depth_one, and
> > svn_depth_infinity. Rev all public APIs that currently take
> > recursive/non-recursive type boolean fields, and make their previous
> > incarnations pass svn_depth_one or svn_depth_infinity instead (except
> > in the 'svn commit' case, where non-recursive means svn_depth_one).
>
> Why not depth 2 or 3? I had thought that depth could be an unsigned
> int 1, return self, 2 expand one level, 3 expand two levels
> etc. Infinite could be 0 or MAX_INT.
>
> Why depth 2? Well it allows you to show if dirs are empty or not without
> suffering the cost of infinite.
Whatever. That's fine. I've no strong opinions on this. FWIW,
mod_dav implements depth in the same way you mentioned, MAX_INT and
all.
> I understand that cat -r BASE will deal with keyword and line ending
> substitutions. Are you saying the svn_client_cat will never work on
> a BASE or WORKING? If so the code should return an error if those
> revisions are passed in.
No, I'm saying only that volunteers (thankfully) tend to de-prioritize
problems that generally have workarounds or that don't interfere with
the daily routines of the average user. For whatever reason, you
think 'svn cat' should work on both WC paths and URLs just like other
subcommands, getting info from the server only when necessary. I
agree. But is that problem more important than the massive list of
other bugs in the tracker? I dunno -- make your case.
I promise you, Barry, that nobody has set out to make your life
difficult, or to avoid adding the functionality you want simply
because it's you. Subversion is a volunteer effort, which means that
most everybody works on exactly what they want to work on, and nothing
else. If your MUST HAVE list isn't being addressed, it's only because
it doesn't match someone else's MUST HAVE list -- no need to freak out
about it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 14 23:37:26 2005