Hi Philip:
I get the behaviour I described on every version of subversion I've
ever tried that has `svn patch`, on various different machines
completely unrelated to each other.
The patch I submitted was against trunk, which I confirmed to have the
bug in my local testing (obviously; I wouldn't submit a patch to fix
something that wasn't happening). I also just reproduced the bug on a
completely unrelated installation of 1.8.0 on a different machine.
As for why it's different on different machines -- it probably depends
on some details in APR. As I mentioned several times, the way the `svn
patch` code works is that it creates a file under /tmp and then copies
it to the final destination. The reason that gives 600 permissions on
the machines I've tried is that `apr_file_mktemp` creates files under
/tmp with 600 permissions.
There are several possible explanations of why it might be different
on different machines, it's not something I have investigated because
I did not expect it to be different on different machines.
Regards,
Cathy
On Fri, Nov 22, 2013 at 3:06 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Cathy Fitzpatrick <cathy_at_cathyjf.com> writes:
>
>> First, `svn patch` is different from some other svn commands in that
>> it always sets mode 600 on the file regardless of umask or anything
>> else.
>
> I see patch setting permissions according to umask. Why are you seeing
> something different? Which version of Subversion are you using?
>
> svnadmin create repo
> svn import -mm repo/format file://`pwd`/repo/f
> svn co file://`pwd`/repo wc
> echo xx >> wc/f
> (cd wc && svn diff) > p
> svn revert -R wc
>
> Now
>
> $ ls -l wc/f
> -rw-r--r-- 1 pm pm 2 Nov 22 10:03 wc/f
> $ (umask 070 && svn patch p wc)
> U wc/f
> $ ls -l wc/f
> -rw----rw- 1 pm pm 5 Nov 22 10:00 wc/f
>
> I get that behaviour with 1.7, 1.8 and trunk.
>
> --
> Philip Martin | Subversion Committer
> WANdisco // *Non-Stop Data*
Received on 2013-11-22 11:13:01 CET