Issue 3445, Error setting property 'log' Could not execute PROPPATCH
Hi. Seems like I have hit with the issue http://subversion.tigris.org/issues/show_bug.cgi?id=3445 Well, it is old report but still open? When committing to https://proxyserver/svn/ the client shows message svn: Commit failed (details follow): svn: At least one property change failed; repository is unchanged svn: Error setting property 'log': Could not execute PROPPATCH. On the master server there is following message in error.log [Fri Mar 18 08:06:46 2011] [error] [client xxx.xxx.xxx.xxx] Could not execute PROPPATCH. [500, #206] [Fri Mar 18 08:06:46 2011] [error] [client xxx.xxx.xxx.xxx] Properties may only be defined in the http://subversion.tigris.org/xmlns/svn/ and http://subversion.tigris.org/xmlns/custom/ namespaces. [409, #0] I had another repository with same setup, https://proxyserver/svnTest/ and commits did work against it. I enabled the content logging on apache, and comparing the data received on server shows subtle difference: http://subversion.tigris.org/xmlns/dav/"; xmlns:C="http://subversion.tigris.org/xmlns/custom/"; xmlns:S="http://subversion.tigris.org/xmlns/svn/";>does it work? for /svntest and http://subversion.tigris.org/xmlns/dav/"; xmlns:C="http://subversion.tigris.org/xmlns/custom/"; xmlns:S="http://subversion.tigris.org/xmlns/";>does it work? for /svn Note the difference in xmlns:S="http://subversion.tigris.org/xmlns/"; xmlns:S="http://subversion.tigris.org/xmlns/svn/"; And yes, the master repo URI has different ending than proxy URI Gert
RE: subversion authz file question
> -Original Message- > From: bruce [mailto:badoug...@gmail.com] > Sent: 18 March 2011 01:36 > To: users@subversion.apache.org > Subject: subversion authz file question > > hi. > > > my question has to do with the structure of the authz access file. > > I'm trying to understand the setup for the "directory" in the file > > as an example, i've seen this: > > [groups] > t=fred,john > > [/] > *= > > [repos:/foo] > > does the [repos:/foo] mean that this is the name of the repos? which > would be the name used when the repos was created? > > or should the [] contain the physical file/dir structure, like: > > [/cat/dog/repos/horse] > > or should it be the portion of the svn http url, right after > the "location" > > i haven't seen a good example on the net that walks through this... > > thanks > Have you read the Subversion Book? Subversion has a really good online manual available and the chapter you need is here:- http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.h tml The third paragraph after the big brown "Do You Really Need Path-Based Access Control?" box should answer your question but it is worth reading the whole page and some of the links. Walkthroughs are great at getting you going but not for granting understanding, that's where the manual comes in! ~ mark c P.S. if you google for "redbean" and some svn keywords, be careful of the URL as google often returns results for older versions (e.g. "1.1"), always look for the '/nightly/' bit.
(Checkout depth != Fully recursive) and svn:externals problem
Yesterday i posted this question at the TortoiseSVN user list: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2712140 Due to the answer of Dale (http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2712147) i'm going to ask the same question here. Unfortunately i'm just one of these dumb windows user unable to use svn from the command line. So i would be glad if someone of you could check if the behaviour of the command line is same as with the TortoiseSVN client and give here a response if it is a bug, a feature, a lack of documentation or just my wrong expectations. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: 'Could not get next bucket brigade' error
On Thu, Mar 17, 2011 at 11:33:41PM -0400, Nico Kadel-Garcia wrote: > The 1.6.16 has some minor build-structure changes that have broken the > SRPM's. I'm wondering if it's even worth pursuing, for environments > that don't rely on HTTP/HTTPS authentication, especially because I'm > such a long-standing deprecator of that approach. (This is because the > Linux and UNIX clients store the passwords for HTTP/HTTPS access in > clear text.) That's not a good reason to neglect a security update. There are folks who need the update. Not that you're obliged to provide one -- you're doing voluntary work, afterall. But I'd expect that a package maintainer to keep the entire userbase in mind. Not just those running particular setups. It's not as if a Subversion HTTP/HTTPS setup was an unsupported use case.
Re: 'Could not get next bucket brigade' error
On Fri, Mar 18, 2011 at 10:07 AM, Stefan Sperling wrote: > On Thu, Mar 17, 2011 at 11:33:41PM -0400, Nico Kadel-Garcia wrote: >> The 1.6.16 has some minor build-structure changes that have broken the >> SRPM's. I'm wondering if it's even worth pursuing, for environments >> that don't rely on HTTP/HTTPS authentication, especially because I'm >> such a long-standing deprecator of that approach. (This is because the >> Linux and UNIX clients store the passwords for HTTP/HTTPS access in >> clear text.) > > That's not a good reason to neglect a security update. There are folks who > need the update. Not that you're obliged to provide one -- you're doing > voluntary work, afterall. But I'd expect that a package maintainer to > keep the entire userbase in mind. Not just those running particular setups. > It's not as if a Subversion HTTP/HTTPS setup was an unsupported use case. You've a point, but enabling people to repeat the errors of mishandling stored passwords is not that high on my priority list. And the creeping changes to the build structure are making it more awkward to maintain. If 1.7.0 is coming out soon, I'm not clear it's worthy my efforts to even bother with this minor release.
Re: 'Could not get next bucket brigade' error
On Fri, Mar 18, 2011 at 10:13:00AM -0400, Nico Kadel-Garcia wrote: > On Fri, Mar 18, 2011 at 10:07 AM, Stefan Sperling wrote: > > On Thu, Mar 17, 2011 at 11:33:41PM -0400, Nico Kadel-Garcia wrote: > >> The 1.6.16 has some minor build-structure changes that have broken the > >> SRPM's. I'm wondering if it's even worth pursuing, for environments > >> that don't rely on HTTP/HTTPS authentication, especially because I'm > >> such a long-standing deprecator of that approach. (This is because the > >> Linux and UNIX clients store the passwords for HTTP/HTTPS access in > >> clear text.) > > > > That's not a good reason to neglect a security update. There are folks who > > need the update. Not that you're obliged to provide one -- you're doing > > voluntary work, afterall. But I'd expect that a package maintainer to > > keep the entire userbase in mind. Not just those running particular setups. > > It's not as if a Subversion HTTP/HTTPS setup was an unsupported use case. > > You've a point, but enabling people to repeat the errors of > mishandling stored passwords is not that high on my priority list. Fair enough. I will stop recommending RPMforge packages until more responsible maintainers show up. > And the creeping changes to the build structure are making it more awkward > to maintain. If 1.7.0 is coming out soon, I'm not clear it's worthy my > efforts to even bother with this minor release. 1.7.0 isn't coming out soon.
Re: 'Could not get next bucket brigade' error
On Fri, Mar 18, 2011 at 10:26 AM, Stefan Sperling wrote: > On Fri, Mar 18, 2011 at 10:13:00AM -0400, Nico Kadel-Garcia wrote: >> On Fri, Mar 18, 2011 at 10:07 AM, Stefan Sperling wrote: >> > On Thu, Mar 17, 2011 at 11:33:41PM -0400, Nico Kadel-Garcia wrote: >> >> The 1.6.16 has some minor build-structure changes that have broken the >> >> SRPM's. I'm wondering if it's even worth pursuing, for environments >> >> that don't rely on HTTP/HTTPS authentication, especially because I'm >> >> such a long-standing deprecator of that approach. (This is because the >> >> Linux and UNIX clients store the passwords for HTTP/HTTPS access in >> >> clear text.) >> > >> > That's not a good reason to neglect a security update. There are folks who >> > need the update. Not that you're obliged to provide one -- you're doing >> > voluntary work, afterall. But I'd expect that a package maintainer to >> > keep the entire userbase in mind. Not just those running particular setups. >> > It's not as if a Subversion HTTP/HTTPS setup was an unsupported use case. >> >> You've a point, but enabling people to repeat the errors of >> mishandling stored passwords is not that high on my priority list. > > Fair enough. > > I will stop recommending RPMforge packages until more responsible > maintainers show up. Oh, my. Let's not get *into* the reponsibility, shall we? Rechecking my test environment, 1.6.16 builds well enough on RHEL 5/CentOS 5 with just the version change. RHEL 6 is a *disaster*, partly due swig integration. (RHEL 6 finally has a recent enough swig and sqlite not to need the separate tarballs, but that code needs graceful management.) The internal ".spec" structure in http://svn.apache.org/repos/asf/subversion/trunk/packages/rpm/ is also *very* dangerous. It replaces the user's own .rpmmacros, without warning and without making a backup. This is hideous behavior. I'll send along some patches for that ASAP. >> And the creeping changes to the build structure are making it more awkward >> to maintain. If 1.7.0 is coming out soon, I'm not clear it's worthy my >> efforts to even bother with this minor release. > > 1.7.0 isn't coming out soon. >
Re: 'Could not get next bucket brigade' error
On Fri, Mar 18, 2011 at 10:40:34AM -0400, Nico Kadel-Garcia wrote: > Rechecking my test environment, 1.6.16 builds well enough on RHEL > 5/CentOS 5 with just the version change. RHEL 6 is a *disaster*, > partly due swig integration. (RHEL 6 finally has a recent enough swig > and sqlite not to need the separate tarballs, but that code needs > graceful management.) > > The internal ".spec" structure in > http://svn.apache.org/repos/asf/subversion/trunk/packages/rpm/ is also > *very* dangerous. It replaces the user's own .rpmmacros, without > warning and without making a backup. This is hideous behavior. I'll > send along some patches for that ASAP. I agree that's hideous. Patches to the packages are welcome. The last serious update seems to have been in 2009. But have you looked at red hat's source RPMs? If RPMforge packages could be based on those, we might as well delete our own packages/rpm/ directory. Build scripts for most Subversion packages these days are maintained elsewhere.
AuthzSVNAccessFile limitations
Hey, guys! I looked everywhere for this info and I have not foud it. I am quiting trying to control access with LDAP groups but I am keeping the authentication. So, I decided to use the AuthzSVNAccessFile directive to make groups and control the access to some repos, projects and paths. I tested with a small groups and it works fine. My problem is that some groups are huge, like hundreds of users. Is there any kind of limitation for this file? Can I specify a group in more than on line? And most important, is there a better way of doing this access management for a big amount of users and groups? Golden question! Rodrigo Montenegro de Oliveira
Re: AuthzSVNAccessFile limitations
On Fri, Mar 18, 2011 at 11:52:51AM -0300, Rodrigo Montenegro wrote: > Hey, guys! > > I looked everywhere for this info and I have not foud it. > > I am quiting trying to control access with LDAP groups but I am keeping the > authentication. > > So, I decided to use the AuthzSVNAccessFile directive to make groups and > control the access to some repos, projects and paths. I tested with a small > groups and it works fine. > My problem is that some groups are huge, like hundreds of users. Is there > any kind of limitation for this file? Can I specify a group in more than on > line? > > And most important, is there a better way of doing this access management > for a big amount of users and groups? Golden question! This might help: http://www.thoughtspark.org/node/26 (second hit on google for "authz ldap groups" BTW :)
Re: 'Could not get next bucket brigade' error
On Fri, Mar 18, 2011 at 10:50 AM, Stefan Sperling wrote:
> On Fri, Mar 18, 2011 at 10:40:34AM -0400, Nico Kadel-Garcia wrote:
>> Rechecking my test environment, 1.6.16 builds well enough on RHEL
>> 5/CentOS 5 with just the version change. RHEL 6 is a *disaster*,
>> partly due swig integration. (RHEL 6 finally has a recent enough swig
>> and sqlite not to need the separate tarballs, but that code needs
>> graceful management.)
>>
>> The internal ".spec" structure in
>> http://svn.apache.org/repos/asf/subversion/trunk/packages/rpm/ is also
>> *very* dangerous. It replaces the user's own .rpmmacros, without
>> warning and without making a backup. This is hideous behavior. I'll
>> send along some patches for that ASAP.
>
> I agree that's hideous.
> Patches to the packages are welcome.
> The last serious update seems to have been in 2009.
>
> But have you looked at red hat's source RPMs? If RPMforge packages could
> be based on those, we might as well delete our own packages/rpm/ directory.
> Build scripts for most Subversion packages these days are maintained
> elsewhere.
I have!!! They only came out a month or so ago as part of RHEL 5.6,
and CentOS hasn't published 5.6 yet, so I've not been working with it
at home. I agree there's potential there: a lot of the RPMforge
weirdness was due to support for RHEL 4, which is now obsolete and
only on "extended support", so a rewrite of that package is
reasonable, but would take considerably longer. And RPMforge is at
least 4 minor releases ahead of RHEL, and it's going to get worse over
time, not better, so RPMforge is still the place to go.
I'm definitely recommending yanking the
http://svn.apache.org/repos/asf/subversion/trunk/packages/rpm/{rhel-3,rhel-4}
directories, those haven't worked in years. Let me spend a bit more
time on the rhel-5 version. I think I can make that one more sane.
cvs log equivalent
SVN experts: The cvs log command includes information about the size of each change: revision 1.14 date: 2010-03-13 18:26:55 -0500; author: pgraham; state: Exp; lines: +331 -288; Rewrote function. revision 1.13 date: 2010-03-04 22:17:56 -0500; author: pgraham; state: Exp; lines: +4 -3; Minor cleanup. It's useful to see when a major change was made to a file. The svn log command lists only log messages, with no information about the magnitude of each change. In fact, I was confused for a while by the svn log output format. It is somewhat similar to the cvs log file output, but the "lines" field is only the number of lines in the log message. It has nothing to do with the actual change made to the file: r7327 | pgraham | 2008-03-07 19:33:42 -0500 (Fri, 07 Mar 2008) | 2 lines Check for null pointer. r7143 | pgraham | 2008-02-07 20:55:01 -0500 (Thu, 07 Feb 2008) | 2 lines Completely rewrite module. Is there any way to get an output similar to cvs log? Paul
Re: cvs log equivalent
On Fri, Mar 18, 2011 at 09:39, Paul Graham wrote: > SVN experts: > > The cvs log command includes information about the size of each change: > > revision 1.14 > date: 2010-03-13 18:26:55 -0500; author: pgraham; state: Exp; lines: +331 > -288; > Rewrote function. > > revision 1.13 > date: 2010-03-04 22:17:56 -0500; author: pgraham; state: Exp; lines: +4 -3; > Minor cleanup. > > It's useful to see when a major change was made to a file. > > The svn log command lists only log messages, with no information about the > magnitude of each change. In fact, I was confused for a while by the svn log > output format. It is somewhat similar to the cvs log file output, but the > "lines" field is only the number of lines in the log message. It has nothing > to do with the actual change made to the file: > > > r7327 | pgraham | 2008-03-07 19:33:42 -0500 (Fri, 07 Mar 2008) | 2 lines > > Check for null pointer. > > > r7143 | pgraham | 2008-02-07 20:55:01 -0500 (Thu, 07 Feb 2008) | 2 lines > > Completely rewrite module. > > > Is there any way to get an output similar to cvs log? Try svn log --verbose Always look to svn help first when you have a question about how a command works. The help provided by Subversion is pretty good.
Re: cvs log equivalent
Andy, Thanks for the reply, but svn log --verbose does not do what I asked about. What I'm interested in is something like cvs log which shows the number of lines affected by the change, e.g., "lines: +10 -5". Paul - Original Message - From: "Andy Levy" To: "Paul Graham" Cc: users@subversion.apache.org Sent: Friday, March 18, 2011 2:20:23 PM Subject: Re: cvs log equivalent On Fri, Mar 18, 2011 at 09:39, Paul Graham wrote: > SVN experts: > > The cvs log command includes information about the size of each change: > > revision 1.14 > date: 2010-03-13 18:26:55 -0500; author: pgraham; state: Exp; lines: +331 > -288; > Rewrote function. > > revision 1.13 > date: 2010-03-04 22:17:56 -0500; author: pgraham; state: Exp; lines: +4 -3; > Minor cleanup. > > It's useful to see when a major change was made to a file. > > The svn log command lists only log messages, with no information about the > magnitude of each change. In fact, I was confused for a while by the svn log > output format. It is somewhat similar to the cvs log file output, but the > "lines" field is only the number of lines in the log message. It has nothing > to do with the actual change made to the file: > > > r7327 | pgraham | 2008-03-07 19:33:42 -0500 (Fri, 07 Mar 2008) | 2 lines > > Check for null pointer. > > > r7143 | pgraham | 2008-02-07 20:55:01 -0500 (Thu, 07 Feb 2008) | 2 lines > > Completely rewrite module. > > > Is there any way to get an output similar to cvs log? Try svn log --verbose Always look to svn help first when you have a question about how a command works. The help provided by Subversion is pretty good.
Re: cvs log equivalent
On Mar 18, 2011, at 08:39, Paul Graham wrote: > The cvs log command includes information about the size of each change: > Is there any way to get an output similar to cvs log? Not with the standard client, no. Perhaps such a thing could be written with a custom script.
Re: cvs log equivalent
I could find all the change versions of a file, then do an svn diff for each change, then parse the output and determine the number of changes, but that seems excessive :-) rcs has this lines+/- information directly in the database. Is svn organized differently under the hood? Paul - Original Message - From: "Ryan Schmidt" To: "Paul Graham" Cc: users@subversion.apache.org Sent: Friday, March 18, 2011 6:41:50 PM Subject: Re: cvs log equivalent On Mar 18, 2011, at 08:39, Paul Graham wrote: > The cvs log command includes information about the size of each change: > Is there any way to get an output similar to cvs log? Not with the standard client, no. Perhaps such a thing could be written with a custom script.
Re: cvs log equivalent
On Fri, Mar 18, 2011 at 6:13 PM, Paul Graham wrote: > I could find all the change versions of a file, then do an svn diff for each > change, then parse the output and determine the number of changes, but that > seems excessive :-) > > rcs has this lines+/- information directly in the database. Is svn organized > differently under the hood? Significantly. One thing I usually do is run svn diff on the revision of interest and then pipe that through diffstat: $ svn diff -c1089374 | diffstat That will usually yield sufficiently interesting result for my application. -Hyrum
Re: AuthzSVNAccessFile limitations
I tested with groups with thousand of users without any problem. All the users are specified in the same line. On 18/03/2011 15:52, Rodrigo Montenegro wrote: Hey, guys! I looked everywhere for this info and I have not foud it. I am quiting trying to control access with LDAP groups but I am keeping the authentication. So, I decided to use the AuthzSVNAccessFile directive to make groups and control the access to some repos, projects and paths. I tested with a small groups and it works fine. My problem is that some groups are huge, like hundreds of users. Is there any kind of limitation for this file? Can I specify a group in more than on line? And most important, is there a better way of doing this access management for a big amount of users and groups? Golden question! Rodrigo Montenegro de Oliveira
