On Mar 14, 2005, at 19:54, C. Michael Pilato wrote:
> Barry Scott <firstname.lastname@example.org> writes:
>>> These are all problems that one or more of Subversion full committers
>>> have been annoyed by -- you aren't alone.
>> Is there a design for the API with a depth param, or do you want
> 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
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.
>> Why is cat so hard to fix? How come diff can do a cat of BASE and a
>> cat of WORKING without contacting the repos? Why don't they share
> Never assume that something doesn't work the way you want because it
> was too hard. 'svn cat' doesn't work on working copy paths because
> there exists for all platforms of interest workarounds:
> $ cat path/to/file
> $ cat path/to/.svn/text-base/file.svn-base
> C:> type path\to\file
> C:> type path\to\file\.svn\text-base\file.svn-base
I understand that cat -r BASE will deal with keyword and line ending
Are you saying the svn_client_cat will never work on a BASE or WORKING?
so the code should return an error if those revisions are passed in.
However if cat -r BASE is useful, and it appears to be, then why does
to contact the repos?
The comments in the issue on this do not support what you are saying
time I read them.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Mar 14 23:23:23 2005