On Wed, 2011-11-09 at 06:28 +0200, Daniel Shahaf wrote:
> On Wednesday, November 09, 2011 11:03 AM, "Tony Butt" <Tony.Butt_at_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
> >
> >
Received on 2011-11-09 06:58:57 CET