Stefan Fuhrmann wrote:
> C. Michael Pilato wrote:
>> Julian Foad wrote:
>>> So shall we get this branch branched very soon? For the sake of making a
>>> decision, I'll suggest that we should try hard to get the things above
>>> resolved by the end of tomorrow, and that even if we don't they are no
On Wed, Apr 10, 2013 at 5:34 PM, C. Michael Pilato wrote:
> On 04/10/2013 11:23 AM, Julian Foad wrote:
> > So shall we get this branch branched very soon? For the sake of making a
> > decision, I'll suggest that we should try hard to get the things above
> > resolved by the end of tomorrow, and t
On Wed, Apr 10, 2013 at 8:33 PM, Daniel Shahaf wrote:
> On Wed, Apr 10, 2013 at 11:34:12AM -0400, C. Michael Pilato wrote:
>> On 04/10/2013 11:23 AM, Julian Foad wrote:
>> > So shall we get this branch branched very soon? For the sake of making a
>> > decision, I'll suggest that we should try har
On Wed, Apr 10, 2013 at 11:34:12AM -0400, C. Michael Pilato wrote:
> On 04/10/2013 11:23 AM, Julian Foad wrote:
> > So shall we get this branch branched very soon? For the sake of making a
> > decision, I'll suggest that we should try hard to get the things above
> > resolved by the end of tomorro
On 04/10/2013 11:23 AM, Julian Foad wrote:
> So shall we get this branch branched very soon? For the sake of making a
> decision, I'll suggest that we should try hard to get the things above
> resolved by the end of tomorrow, and that even if we don't they are not
> blockers, so:
>
> Let's branch
Let's move this along.
C. Michael Pilato wrote:
> Finally, as a special request, I'm going to ask that Paul and Julian work
> together on that final bit of merge-function-related review from
> svn_client.h -- their two sets of combined can ensure that these APIs are OK
> for release much more so
On Tue, Apr 2, 2013 at 6:01 AM, Julian Foad wrote:
> Should be "an absolute dirent", since dirents can also be relative and I
> understood that these functions require them to be absolute.
No requirement that the dirent be absolute. We use absolute dirents
in our servers out of security paranoi
Ben Reser wrote:
> On Mon, Apr 1, 2013 at 9:01 PM, Ben Reser wrote:
>> I changed it to say "a dirent" which fits with our naming scheme for
>> types of paths.
Should be "an absolute dirent", since dirents can also be relative and I
understood that these functions require them to be absolute.
>>
On Mon, Apr 1, 2013 at 9:01 PM, Ben Reser wrote:
> Done along with the doc change mentioned above in r1463374.
Glad I ended up looking at this. Found two security holes in
mod_authz_svn that we introduced in trunk. Both caused by the
improper handling of the cache_key. I added the one when I a
On Mon, Apr 1, 2013 at 10:34 AM, Ben Reser wrote:
> On Mon, Apr 1, 2013 at 9:27 AM, Julian Foad
> wrote:
>> First we need to clarify what "@a path (a file,)" means. From the
>> discussion below I gather "a file" means an absolute local filesystem path,
>> so let's say so.
>
> Yes absolute OS
On 4/1/13 10:25 AM, C. Michael Pilato wrote:
On 03/31/2013 12:31 AM, Blair Zajac wrote:
Question on svn_repos_load_fs4() and svn_repos_get_fs_build_parser4() (maybe
other functions have a similar text):
* @note If @a start_rev and @a end_rev are valid revisions, this
* function presumes the
On Mon, Apr 1, 2013 at 9:27 AM, Julian Foad wrote:
> First we need to clarify what "@a path (a file,)" means. From the discussion
> below I gather "a file" means an absolute local filesystem path, so let's say
> so.
Yes absolute OS filesystem path. I prefer saying OS filesystem path
because it
On 03/31/2013 12:31 AM, Blair Zajac wrote:
> Question on svn_repos_load_fs4() and svn_repos_get_fs_build_parser4() (maybe
> other functions have a similar text):
>
> * @note If @a start_rev and @a end_rev are valid revisions, this
> * function presumes the revisions as numbered in @a dumpstream
Here's the current doc string of svn_repos_authz_read2():
/**
* Read authz configuration data from @a path (a file, repos relative
* url, an absolute file url, or a registry path) into @a *authz_p,
* allocated in @a pool.
*
* If @a groups_path (a file, repos relative url, an absolute file ur
On Sun, Mar 31, 2013 at 5:58 AM, Daniel Shahaf wrote:
> How about forbidding PATH to be a repos-relative URL, but permitting it
> to be a relpath, that is then interpreted relative to the repos root.
> The conversion is trivial, just +2 on the argument, but it avoids
> "non-canonical" and "^/ URLs
On 04/01/2013 11:25 AM, C. Michael Pilato wrote:
> On 03/31/2013 12:31 AM, Blair Zajac wrote:
>> Question on svn_repos_load_fs4() and svn_repos_get_fs_build_parser4() (maybe
>> other functions have a similar text):
>>
>> * @note If @a start_rev and @a end_rev are valid revisions, this
>> * functi
On 03/31/2013 12:31 AM, Blair Zajac wrote:
> On 03/29/2013 01:17 PM, C. Michael Pilato wrote:
>> Devs,
>>
>> I've just completed my review of the new-in-1.8 public APIs, minus the bits
>> that Philip reviewed (thanks!) and the new merge-related stuff which, if I
>> understand from recent threads co
On 03/30/2013 02:26 PM, Stefan Fuhrmann wrote:
> r1462828 addresses the issues listed for svn_fs.h and svn_ra_svn.h.
> Please review.
The zero-copy-limit stuff looks good. I don't quite understand the bit
about svn_fs_verify() possibly ignoring the 'start' and 'end' parameters
altogether. From c
Ben Reser wrote on Sun, Mar 31, 2013 at 00:24:56 -0700:
> On Fri, Mar 29, 2013 at 1:17 PM, C. Michael Pilato
> wrote:
> > Please note especially the section labeled "Reviewed But Need Further
> > Attention". In it, I call out some of the stuff about which I couldn't come
> > to clear and obvious
On Fri, Mar 29, 2013 at 1:17 PM, C. Michael Pilato wrote:
> Please note especially the section labeled "Reviewed But Need Further
> Attention". In it, I call out some of the stuff about which I couldn't come
> to clear and obvious conclusion/solution/etc. Please take a moment to
> review that se
On 03/29/2013 01:17 PM, C. Michael Pilato wrote:
Devs,
I've just completed my review of the new-in-1.8 public APIs, minus the bits
that Philip reviewed (thanks!) and the new merge-related stuff which, if I
understand from recent threads correctly, is still subject to some churn.
The results of
On Fri, Mar 29, 2013 at 9:17 PM, C. Michael Pilato wrote:
> Devs,
>
> I've just completed my review of the new-in-1.8 public APIs, minus the bits
> that Philip reviewed (thanks!) and the new merge-related stuff which, if I
> understand from recent threads correctly, is still subject to some churn.
22 matches
Mail list logo
