On Wed, 2011-11-09 at 06:28 +0200, Daniel Shahaf wrote: > On Wednesday, November 09, 2011 11:03 AM, "Tony Butt" <tony.b...@cea.com.au> > wrote: > > On Tue, 2011-11-08 at 13:50 +0200, Daniel Shahaf wrote: > > > Tony Butt wrote on Tue, Nov 08, 2011 at 15:07:55 +1100: > > > > Hi all, > > > > > > > > We have recently upgraded our subversion servers from 1.6.17 to 1.7.1, > > > > and as I usually do when making the 'semi-major' upgrade, dumped and > > > > reloaded the repository. > > > > > > > > > > 1.6 and 1.7 use the same backend format. dump/load gains nothing. And > > > the release notes say that... > > Yes, I found that out the day after I went throught the dunp/load > > process. The back end format may be the same, but the file permissions > > are not, which has had a flow-on effect to our current practices. > > > > > > > Here I noticed 2 things: > > > > 1) the individual revs and revprops files are now read-only, previously > > > > they were read/write for group and owner. > > > > 2) the svn+ssh committed files were owned by the committing user (myself > > > > in the test case) > > > > > > > > I tried to edit the log message of a commit made with svn+ssh://, using > > > > http:// access, and failed. Now the strange thing, after changing a > > > > different commit message for a test (using http:// access only, > > > > successsfully), drafting this email, and re-checking the revprops file > > > > in question, it was now owned by www-data - the apache user. > > > > > > > > > > We make rev files read only intentionally. I don't remember offhand > > > how revprop files would be affected, but in any case those are never > > > changed either --- we only ever rename(2) new versions on top of old > > > ones. > > > > > > And, anyway, I really don't understand your bottom line. Are you saying > > > the new behaviour is non backwards compatible? That it should be > > > changed? Or just that it's surprising? > > The new behaviour is slightly different, and slightly incompatible in > > our corner case. It was more surprising than anything else, and I wanted > > to check that I didn't need to tweak the repository config in some way > > to allow for this - possibly some subtlety with umasks that I was not > > aware of. > > > > > > > In short, this is unexpected behaviour for me, but not exactly broken. > > > > > > > > Tony Butt > > > > CEA Technologies > > > > Canberra > > > > > > Next time can you try to be more concise, rather than bury your question > > > somewhere in the middle. Thanks. > > OK - Repository behaviour is slightly different to 1.6.17, as detailed > > (verbosely) above. Asking for advice as to whether this is a defect, > > or configuration error. This may bite anyone that uses multiple access > > methods and revprop edits. Humour intended too. :-) > > > > There was a code change, by me, intending to make revision files read-only to > try and make it harder to corrupt them. (This was motivated by some > corruption bug that Philip filed, reproduced via gdb, and then added code to > detect.) > > Sorry for brief / lack of details, enotime this morning, I'll look again > later, Thanks Daniel, For me, this is truly a corner case. Some time ago, we struggled with the performance of http:// access, so went to svn+ssh:// as an alternate. Those issues are long gone, but we still have a few long lived working copies with svn+ssh:// access, one of which triggered our problem. The work-around, of course, is trivial, either relocate the WC to the http:// access, or just remove it and check it out again.
We still need svn+ssh is some form, as we have an overnight build process that uses it, otherwise I would just remove it completely. In terms of reproducing, if you want to, you need 1) A 1.7.1 repository with http:// and svn+ssh:// access methods configured. 2) property updates enabled - we allow log message and user name to be updated. 3) Commit anything using http://, then edit the log message using svn +ssh:// I used TortoiseSVN only as a client as it was convenient. I will try testing the command line client tomorrow for my own curiosity. Tony Butt CEA Technologies Canberra > > > Thanks, > > Tony Butt > > CEA Technologies > > Canberra > > > >
