On Wed, Mar 27, 2013 at 6:58 PM, Joe Swatosh wrote:
> On Wed, Mar 27, 2013 at 4:03 AM, Stefan Sperling wrote:
>> On Wed, Mar 27, 2013 at 10:25:16AM +, Philip Martin wrote:
>>> Joe Swatosh writes:
>>>
>>> > Okay, thanks for giving me hints on this. As a matter of fact, my apr
>>> > does NOT h
On Wed, Mar 27, 2013 at 4:03 AM, Stefan Sperling wrote:
> On Wed, Mar 27, 2013 at 10:25:16AM +, Philip Martin wrote:
>> Joe Swatosh writes:
>>
>> > Okay, thanks for giving me hints on this. As a matter of fact, my apr
>> > does NOT have a section like this. It is just doing a straight up copy
Daniel Shahaf wrote on Wed, Mar 27, 2013 at 23:31:29 +0200:
> Branko Čibej wrote on Wed, Mar 27, 2013 at 12:57:13 +0100:
> > On 27.03.2013 07:54, Daniel Shahaf wrote:
> > > Branko Čibej wrote on Wed, Mar 27, 2013 at 05:14:51 +0100:
> > >> On 26.03.2013 23:11, Daniel Shahaf wrote:
> > >>> [[[
> > >>
Branko Čibej wrote on Wed, Mar 27, 2013 at 12:57:13 +0100:
> On 27.03.2013 07:54, Daniel Shahaf wrote:
> > Branko Čibej wrote on Wed, Mar 27, 2013 at 05:14:51 +0100:
> >> On 26.03.2013 23:11, Daniel Shahaf wrote:
> >>> [[[
> >>> Run the per-revision verify code on a transaction just before it becom
Stefan, the point of that debug code was to prevent anything from later
modifying the original svn_stringbuf_t object, because that could change or
invalidate the memory pointed to by the new svn_string_t alias.
- Julian
> Author: stefan2
> Date: Wed Mar 27 19:45:25 2013
> New Revision: 1461
s...@apache.org wrote on Wed, Mar 27, 2013 at 17:19:58 -:
> Author: stsp
> Date: Wed Mar 27 17:19:57 2013
> New Revision: 1461725
>
> URL: http://svn.apache.org/r1461725
> Log:
> * subversion/libsvn_fs_fs/tree.c
> (escape_newline): Replace a hand-rolled loop with strchr() call.
>
> Modified
On Wed, Mar 27, 2013 at 10:01:01AM -0700, Ben Reser wrote:
> > Something like the proposal above, to reject LF only at the FS (or FSFS)
> > layer, and all control characters in libsvn_repos, sounds good to me.
> > We should write unit tests to ensure that the FS layer works
> > properly with all o
On Wed, Mar 27, 2013 at 12:18 PM, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: stef...@apache.org [mailto:stef...@apache.org]
> > Sent: woensdag 27 maart 2013 12:15
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1461521 - /subversion/branches/1.7.x/STATUS
> >
On Wed, Mar 27, 2013 at 01:09:00PM -0400, C. Michael Pilato wrote:
> I don't spot any run-time checks for the disallowed '.' and '..' components.
They are in svn_fs__path_valid(), libsvn_fs/fs-loader.c.
On 03/27/2013 12:12 PM, Julian Foad wrote:
> My thoughts:
>
> The key issue is we need to define 'valid path' for the FS layer, and
> follow through with documenting it, implementing run-time checks, and
> testing it.
The definition of a 'valid path' for the FS layer has existed since long
before
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
- Original Message -
> From: Mark Phippard
> To: Julian Foad
> Cc: "b...@qqmail.nl" ; Stefan Sperling ;
> Subversion Development ; Stefan Küng
>
> Sent: Wednesday, 27 March 2013, 1
On Wed, Mar 27, 2013 at 9:12 AM, Julian Foad wrote:
> So there is a compromise between the theoretical
> independence which allows FS to have a different definition of valid
> filenames, and the practical issue that if we actually do make it
> different from the repos layer's definition then it's
On Wed, Mar 27, 2013 at 12:18 PM, Julian Foad
wrote:
> Brane told me that while updating the JavaHL API he noticed that the new
> svn_client_merge_automatic() is Yet Another Merge API, and would prefer make
> the existing JavaHL merge API encompass that functionality rather than add
> yet anoth
On 27.03.2013 17:18, Julian Foad wrote:
> Brane told me that while updating the JavaHL API he noticed that the new
> svn_client_merge_automatic() is Yet Another Merge API, and would prefer make
> the existing JavaHL merge API encompass that functionality rather than add
> yet another variant. S
On Wed, Mar 27, 2013 at 12:22 PM, Julian Foad
wrote:
> Discussing the behaviour of the backward-compatibility APIs:
>
>
> Bert wrote:
>> I don't think the strict ordening will be a problem for old clients at the
>> client level. We don't promis ordering in the ra layers anyway and we have
>> chang
Discussing the behaviour of the backward-compatibility APIs:
Bert wrote:
> I don't think the strict ordening will be a problem for old clients at the
> client level. We don't promis ordering in the ra layers anyway and we have
> changed the ordering many times before. As long as we call the callb
Brane told me that while updating the JavaHL API he noticed that the new
svn_client_merge_automatic() is Yet Another Merge API, and would prefer make
the existing JavaHL merge API encompass that functionality rather than add yet
another variant. So I said if let's see if we can apply that idea
Stefan Sperling wrote:
> C. Michael Pilato wrote:
>> On 03/27/2013 11:03 AM, Stefan Sperling wrote:
>> > That's fine. The fix I've committed and proposed for backport applies
>> > the large hammer and blocks any control characters. If there's a case
>> > to be made for relaxing this check I'm
On 27.03.2013 16:24, Ivan Zhakov wrote:
> On Wed, Mar 27, 2013 at 7:20 PM, C. Michael Pilato
> wrote:
>> On 03/27/2013 11:03 AM, Stefan Sperling wrote:
>>> On Wed, Mar 27, 2013 at 10:52:04AM -0400, C. Michael Pilato wrote:
> I think we'll have to block these paths at the FS layer.
If FSF
Stefan Sperling wrote on Wed, Mar 27, 2013 at 16:39:47 +0100:
> What about:
>
> - We make the FS layer check for newlines (because we know FSFS can't cope)
>
I think the newlines check should be in FSFS, not in libsvn_fs.
> - We make the repos layer check for control characters (because the
On Wed, Mar 27, 2013 at 11:20:54AM -0400, C. Michael Pilato wrote:
> On 03/27/2013 11:03 AM, Stefan Sperling wrote:
> > That's fine. The fix I've committed and proposed for backport applies
> > the large hammer and blocks any control characters. If there's a case
> > to be made for relaxing this ch
On Wed, Mar 27, 2013 at 7:20 PM, C. Michael Pilato wrote:
> On 03/27/2013 11:03 AM, Stefan Sperling wrote:
>> On Wed, Mar 27, 2013 at 10:52:04AM -0400, C. Michael Pilato wrote:
I think we'll have to block these paths at the FS layer.
>>>
>>> If FSFS is fundamentally unable to support these ty
On 03/27/2013 11:03 AM, Stefan Sperling wrote:
> On Wed, Mar 27, 2013 at 10:52:04AM -0400, C. Michael Pilato wrote:
>>> I think we'll have to block these paths at the FS layer.
>>
>> If FSFS is fundamentally unable to support these types of paths, then sure,
>> let's go ahead and protect against th
Stefan Sperling wrote on Wed, Mar 27, 2013 at 16:03:32 +0100:
> On Wed, Mar 27, 2013 at 10:52:04AM -0400, C. Michael Pilato wrote:
> > > I think we'll have to block these paths at the FS layer.
> >
> > If FSFS is fundamentally unable to support these types of paths, then sure,
> > let's go ahead a
On 03/27/2013 11:04 AM, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Wed, Mar 27, 2013 at 10:56:40 -0400:
>> On 03/26/2013 06:03 PM, danie...@apache.org wrote:
>>> Author: danielsh
>>> Date: Tue Mar 26 22:03:19 2013
>>> New Revision: 1461335
>>>
>>> URL: http://svn.apache.org/r1461335
>>> Log:
C. Michael Pilato wrote on Wed, Mar 27, 2013 at 10:56:40 -0400:
> On 03/26/2013 06:03 PM, danie...@apache.org wrote:
> > Author: danielsh
> > Date: Tue Mar 26 22:03:19 2013
> > New Revision: 1461335
> >
> > URL: http://svn.apache.org/r1461335
> > Log:
> > FS: Allow the 'verify' API to run against
On Wed, Mar 27, 2013 at 10:52:04AM -0400, C. Michael Pilato wrote:
> > I think we'll have to block these paths at the FS layer.
>
> If FSFS is fundamentally unable to support these types of paths, then sure,
> let's go ahead and protect against the failure at that level. But please
> don't overre
On 03/26/2013 06:03 PM, danie...@apache.org wrote:
> Author: danielsh
> Date: Tue Mar 26 22:03:19 2013
> New Revision: 1461335
>
> URL: http://svn.apache.org/r1461335
> Log:
> FS: Allow the 'verify' API to run against transaction roots.
>
> * subversion/include/svn_fs.h
> (svn_fs_verify_rev): C
On 03/27/2013 08:35 AM, Stefan Sperling wrote:
> On Tue, Mar 26, 2013 at 06:42:27PM +0100, Stefan Sperling wrote:
>> On Tue, Mar 26, 2013 at 12:40:56PM -0400, C. Michael Pilato wrote:
>>> Certainly, libsvn_repos should be disallowing newline-bearing paths. We
>>> weren't able to support these path
Bert Huijben wrote:
> Philip Martin wrote:
>> "svn add" won't add files that set both a binary svn:mime-type and an
>> svn:eol-style. The low level function that checks the properties has a
>> skip_some_checks flag to allow the combination which is how both
>> properties can be set using "svn
On Wed, Mar 27, 2013 at 04:55:46PM +0400, Ivan Zhakov wrote:
> I think easiest way to block these paths in svn_fs_make_file() not in
> commit_txn(). We already perform path validation in make_file().
Yes, that's right, and I'll do that now.
The reason I attempted to do this in repos_commit_txn()
On Wed, Mar 27, 2013 at 3:55 PM, wrote:
> Author: stsp
> Date: Wed Mar 27 11:55:10 2013
> New Revision: 1461542
>
> URL: http://svn.apache.org/r1461542
> Log:
> Follow-up to r1461535:
>
> * subversion/tests/libsvn_repos/repos-test.c
> (filename_trailing_newline): Tweak this test to verify behav
On Wed, Mar 27, 2013 at 01:35:30PM +0100, Stefan Sperling wrote:
> Let's face it, the FS API promise people are upholding in this discussion
> has been broken for years.
FWIW, here's the patch I was trying to use:
Index: subversion/libsvn_repos/fs-wrap.c
==
On Tue, Mar 26, 2013 at 06:42:27PM +0100, Stefan Sperling wrote:
> On Tue, Mar 26, 2013 at 12:40:56PM -0400, C. Michael Pilato wrote:
> > Certainly, libsvn_repos should be disallowing newline-bearing paths. We
> > weren't able to support these paths when our .svn/entries file was
> > plaintext, we
On Wed, Mar 27, 2013 at 01:16:58PM +0100, Bert Huijben wrote:
> >SVN_TEST_ASSERT(err != SVN_NO_ERROR);
> > + svn_error_clear(err);
> > + svn_pool_clear(subpool);
>
> I think there is some SVN_TEST_ macro that tests for a specific error code
> and then clears the error for you.
>
> That wou
> -Original Message-
> From: s...@apache.org [mailto:s...@apache.org]
> Sent: woensdag 27 maart 2013 12:55
> To: comm...@subversion.apache.org
> Subject: svn commit: r1461542 -
> /subversion/trunk/subversion/tests/libsvn_repos/repos-test.c
>
> Author: stsp
> Date: Wed Mar 27 11:55:10 201
On 27.03.2013 07:54, Daniel Shahaf wrote:
> Branko Čibej wrote on Wed, Mar 27, 2013 at 05:14:51 +0100:
>> On 26.03.2013 23:11, Daniel Shahaf wrote:
>>> [[[
>>> Run the per-revision verify code on a transaction just before it becomes
>>> a revision. The intent is to catch corruption bugs as early a
> -Original Message-
> From: stef...@apache.org [mailto:stef...@apache.org]
> Sent: woensdag 27 maart 2013 12:15
> To: comm...@subversion.apache.org
> Subject: svn commit: r1461521 - /subversion/branches/1.7.x/STATUS
>
> Author: stefan2
> Date: Wed Mar 27 11:14:31 2013
> New Revision: 14
On Wed, Mar 27, 2013 at 10:25:16AM +, Philip Martin wrote:
> Joe Swatosh writes:
>
> > Okay, thanks for giving me hints on this. As a matter of fact, my apr
> > does NOT have a section like this. It is just doing a straight up copy
> > of apr.hw. I've downloaded a few different versions of ap
Joe Swatosh writes:
> Okay, thanks for giving me hints on this. As a matter of fact, my apr
> does NOT have a section like this. It is just doing a straight up copy
> of apr.hw. I've downloaded a few different versions of apr and none of
> them have a block like that in apr.hw. Heading over to th
I'm not sure why this log message contains r1453780 too? The mergeinfo
diff doesn't list that revision.
Perhaps it's due to the line with four spaces between the two entries...
svn-r...@apache.org wrote on Wed, Mar 27, 2013 at 04:00:33 -:
> Author: svn-role
> Date: Wed Mar 27 04:00:32 2013
41 matches
Mail list logo
