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. 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? Is it difficult to patch svn cp? How much time would YOU need? svn cp should always make the target file read-write in the working copy. Sounds like one command somewhere near the end of svn cp, isn't it? What do you think? Paul > -----Ursprüngliche Nachricht----- > Von: Stefan Sperling [mailto:s...@elego.de] > Gesendet: Donnerstag, 14. Oktober 2010 12:02 > An: Paul Maier > Cc: users@subversion.apache.org > Betreff: Re: Bug report against SVN 1.6.13 > > On Thu, Oct 14, 2010 at 01:42:36AM +0200, Paul Maier wrote: > > Hi there! > > > > file b should be read-write here; what do you think: > > > > > > Reproduction script: > > -------------------- > > svn --version > > svnadmin create xx > > svn co "file:///C:/[...]/xx" yy > > cd yy > > echo a > a > > svn add a > > svn propset svn:needs-lock "*" a > > svn ci -m "" > > svn up > > svn cp a b > > ls -lA > > > > > > Observed behaviour: > > ------------------- > > File b is read-only. > > No svn command is available to make file b read-write. > > svn lock won't do, because file b is not in the repository yet. > > Even a "svn lock a" before the copy doesn't help out. > > > > > > Expected behaviour: > > ------------------- > > File b is read-write. > > Files without representation in the repository (files that > come from a > > uncommitted svn cp or svn mv) should be read-write regardless > > svn:needs-lock setting. > > I'm fine with this idea if the file is also made read-only > after commit. > > Would you like to try to write a patch against Subversion trunk that > implements this feature? (I wouldn't really call it a "bug". A bug is > when something doesn't work as designed. In this case, it seems like > the designers of the lock feature didn't care or overlooked > this issue, > so the desired behaviour is simply "unspecified".) > > Stefan
