[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion repository config problem

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 09 Nov 2011 06:28:21 +0200

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,
> Tony Butt
> CEA Technologies
> Canberra
>
>
Received on 2011-11-09 05:29:05 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.