On Fri, Oct 15, 2010 at 10:13:48PM +0200, Paul Maier wrote: > Hi Stefan! > > Thank you for having responded. > > Of course, after the commit, the file is read-only. > > Sorry. I don't know how to implement this. But it pains me a lot.
You'd need to be able to read and write C code. > So I need to look for a crack, who is interested in implementing this? > Or how is the procedure? Do I have to go through some steps to have > my idea put into the issue tracker, and then wait until an > implementor graps it? You can file an issue describing your idea. Make sure to add a link to the mailing list archives, so people who find the issue will find this thread. You can use this link: http://svn.haxx.se/users/archive-2010-10/0228.shtml Then you'll need to wait until someone decides to pick up the task, if you cannot do it yourself. Until then, you'll need to work around the problem by manually marking such files read/write using operating system tools. > Is it difficult to patch svn cp? How much time would YOU need? I don't know how long it would take me. And I don't know if or when I'll find the time to do it. > svn cp should always make the target file read-write in the > working copy. No. A plain copy should carry file permissions of its source along, just like a normal (operating system) copy command does. Only in the special case where an uncommitted file has an svn:needs-lock property it should be read-write, because: 1) There is no way to get the lock to make the file read-write, so there's no point in having the file read-only 2) Noone else can see the file yet, anyway > Sounds like one command somewhere near the end of svn cp, isn't it? I'd poke around in the code to see where the svn:needs-lock property is handled, and try to add a special case there for files which are locally added or copied.
