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.mar...@wandisco.com> wrote: > Cathy Fitzpatrick <ca...@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*
