patch on files with svn:keywords ends up with 0600 perms

2019-07-26 Thread Doug Robinson
Committers, et. al.:

This was just sent to us by a customer.  We've verified on at 1.10.4.  I
checked in JIRA and didn't find a matching bug.  Should I create a new JIRA?


$ svnadmin create test_repo

$ svn co file:///tmp/test_repo accnt
Checked out revision 0.

$ cd accnt/
$ touch a.c b.c
$ svn add a.c b.c
A a.c
A b.c

# Adding property only on a.c
$ svn propset svn:keywords "Id Revision Date URL Author Header" a.c
property 'svn:keywords' set on 'a.c'
$ ls -l
total 0
-rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 a.c
-rw-r--r-- 1 accnt qa-others 0 Jul 25 13:47 b.c
$ svn commit -m "test commit"
Adding a.c
Adding b.c
Transmitting file data ..done
Committing transaction...
Committed revision 1.
$ svn patch /tmp/patch
U a.c
> applied hunk @@ -0,0 +1,1 @@ with offset 0
U b.c
> applied hunk @@ -0,0 +1,1 @@ with offset 0

# After applying patch the permission on the file with property
svn:keywords has changed.
$ ls -l
total 8
-rw--- 1 accnt qa-others 11 Jul 25 13:49 a.c
-rw-r--r-- 1 accnt qa-others 28 Jul 25 13:49 b.c

$ umask
0022

# The patch applied:
$ cat /tmp/patch
Index: a.c
===
--- a.c (revision 1)
+++ a.c (working copy)
@@ -0,0 +1 @@
+test patch
Index: b.c
===
--- b.c (revision 1)
+++ b.c (working copy)
@@ -0,0 +1 @@
+test patch without keywords

-- 
*DOUGLAS B ROBINSON* SENIOR PRODUCT MANAGER

T +1 925 396 1125
*E* doug.robin...@wandisco.com

-- 


* *

**The LIVE DATA Company
*Find out more 
*wandisco.com *



 

*


THIS MESSAGE 
AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY BE PRIVILEGED

If 
this message was misdirected, WANdisco, Inc. and its subsidiaries, 
("WANdisco") does not waive any confidentiality or privilege. If you are 
not the intended recipient, please notify us immediately and destroy the 
message without disclosing its contents to anyone. Any distribution, use or 
copying of this email or the information it contains by other than an 
intended recipient is unauthorized. The views and opinions expressed in 
this email message are the author's own and may not reflect the views and 
opinions of WANdisco, unless the author is authorized by WANdisco to 
express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by WANdisco. 
Although WANdisco operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.


Re: 1.9.12 test failure

2019-07-26 Thread Nathan Hartman
On Fri, Jul 26, 2019 at 12:08 PM Mark Phippard  wrote:

> On Jul 26, 2019, at 12:06 PM, Nathan Hartman 
> wrote:
>
> On Fri, Jul 19, 2019 at 6:03 PM Daniel Shahaf 
> wrote:
>
>> Also, I can't think of a reason why you shouldn't sign the tarballs.
>>
>
> I was under the impression that a signature is only meaningful when the
> signer is a committer. :-)
>
>
> The signature only counts as a binding vote for the release when it is
> from a committer but in terms of strengthening the web of trust we ought to
> accept a signature from anyone.
>

In that case, I'll be happy to do that in the future. :-)


Re: 1.9.12 test failure

2019-07-26 Thread Mark Phippard

> On Jul 26, 2019, at 12:06 PM, Nathan Hartman  wrote:
> 
>> On Fri, Jul 19, 2019 at 6:03 PM Daniel Shahaf  
>> wrote:
> 
>> Nathan Hartman wrote on Fri, 19 Jul 2019 17:32 +00:00:
>> > I meant is there a script that generates the list of dependencies
>> > actually used on the test system. E.g., as in this testing/signing
>> > message from a prior release:
>> > 
>> > https://svn.haxx.se/dev/archive-2019-04/0012.shtml
>> > 
>> > Because even though I'm not signing, I'd like to report what was actually 
>> > used.
>> 
>> There's 'svn --version --verbose', and I think stsp's distro 
>> (tools/dev/unix-build/)
>> has a target for this too, but beyond that, I don't think there's a single 
>> script
>> you can use.  Many developers use Debian derivatives, though; perhaps one of
>> them will share a script you can use.
>> 
>> People usually report what test combinations they ran.  (That basically
>> means what FS backend and RA layer you tested.  If you set any relevant
>> 'make'- or 'make check'-time knobs, it's useful to say that, too.)
>> 
>> Also, I can't think of a reason why you shouldn't sign the tarballs.
>> 
>> Thanks for testing,
>> 
>> Daniel
> 
> Thanks. That does make it much easier to include the dependency info
> for future tests.
> 
> I was under the impression that a signature is only meaningful when the
> signer is a committer. :-)
> 
> Glad to help. Thanks to everyone for the latest Subversion releases!

The signature only counts as a binding vote for the release when it is from a 
committer but in terms of strengthening the web of trust we ought to accept a 
signature from anyone.

Mark


Re: 1.9.12 test failure

2019-07-26 Thread Nathan Hartman
On Fri, Jul 19, 2019 at 6:03 PM Daniel Shahaf 
wrote:

> Nathan Hartman wrote on Fri, 19 Jul 2019 17:32 +00:00:
> > I meant is there a script that generates the list of dependencies
> > actually used on the test system. E.g., as in this testing/signing
> > message from a prior release:
> >
> > https://svn.haxx.se/dev/archive-2019-04/0012.shtml
> >
> > Because even though I'm not signing, I'd like to report what was
> actually used.
>
> There's 'svn --version --verbose', and I think stsp's distro
> (tools/dev/unix-build/)
> has a target for this too, but beyond that, I don't think there's a single
> script
> you can use.  Many developers use Debian derivatives, though; perhaps one
> of
> them will share a script you can use.
>
> People usually report what test combinations they ran.  (That basically
> means what FS backend and RA layer you tested.  If you set any relevant
> 'make'- or 'make check'-time knobs, it's useful to say that, too.)
>
> Also, I can't think of a reason why you shouldn't sign the tarballs.
>
> Thanks for testing,
>
> Daniel
>

Thanks. That does make it much easier to include the dependency info
for future tests.

I was under the impression that a signature is only meaningful when the
signer is a committer. :-)

Glad to help. Thanks to everyone for the latest Subversion releases!