mod_dav_svn: nested Location '/svn' hinders access to '' in SVNPath Location '/svn'
Hi Team, We recently upgraded subversion from 1.6 version to 1.8 version on RHEL 5.8. After upgrade we are getting below warning in error_log file and we are getting access denied error when we try to access projects thru URL and forbidden error when we checkout using client. Before upgrade everything was working fine. "mod_dav_svn: nested Location '/svn' hinders access to '' in SVNPath Location '/svn'" DAV svn #AuthLDAPEnabled on SVNListParentPath on SVNAutoversioning on SVNReposName "svn repository" SVNParentPath /u10//svnrepositories AuthType Basic AuthName "Subversion" #AuthExternal ldap_auth #Require valid-user AuthzLDAPAuthoritative on AuthType Basic AuthBasicProvider ldap AuthName "Subversion" AuthLDAPBindDN "cn=~~,l=~~,dc=~~,dc=com" AuthLDAPBindPassword pass AuthLDAPURL "LDAP URL" Require valid-user AuthzSVNAccessFile /u10//svnauthfile I am new to SVN. Could someone please help me to resolve this issue. Thanks -- View this message in context: http://subversion.1072662.n5.nabble.com/mod-dav-svn-nested-Location-svn-hinders-access-to-in-SVNPath-Location-svn-tp196311.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: What branching patterns work with Subversion reintegrate merge?
Thanks for your reply Stefan. It's very much appreciated. Before Subversion 1.8 made the reintegrate merge automatic, I was doing merges without the reintegrate option, which were, I suppose, inappropriate "complete merges". They were generally effective, but sometimes produced errors and strange conflicts. With Subversion 1.8 or higher, I am forced to cherry-pick, which may sometimes produce poor results if I pick the wrong cherries. I had regarded cherry-picking as error-prone and something to be avoided, but it's good to know that it's used successfully elsewhere. Bob From: Stefan Sperling Sent: Saturday, March 19, 2016 11:10 AM To: Bob Berger Cc: users@subversion.apache.org Subject: Re: What branching patterns work with Subversion reintegrate merge? On Fri, Mar 18, 2016 at 08:22:06PM +, Bob Berger wrote: > Subversion requires you to do a sync merge from your trunk to a branch, > before you can do a reintegrate merge from the branch back to the trunk. But > the sync merge seems incompatible with a branching pattern where the trunk > contains ongoing development and branches contain releases Use cherry-picking merges. 'svn help merge' (output qouted below) contains all you need to know. The Subversion project itself uses the branching pattern you describe, so I'm quite sure it works and is fully supported ;-) If you want to read about our workflow, see here: http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization merge: Merge changes into a working copy. usage: 1. merge SOURCE[@REV] [TARGET_WCPATH] (the 'complete' merge) 2. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [TARGET_WCPATH] (the 'cherry-pick' merge) 3. merge SOURCE1[@REV1] SOURCE2[@REV2] [TARGET_WCPATH] (the '2-URL' merge) 1. This form, with one source path and no revision range, is called a 'complete' merge: svn merge SOURCE[@REV] [TARGET_WCPATH] The complete merge is used for the 'sync' and 'reintegrate' merges in the 'feature branch' pattern described below. It finds all the changes on the source branch that have not already been merged to the target branch, and merges them into the working copy. Merge tracking is used to know which changes have already been merged. SOURCE specifies the branch from where the changes will be pulled, and TARGET_WCPATH specifies a working copy of the target branch to which the changes will be applied. Normally SOURCE and TARGET_WCPATH should each correspond to the root of a branch. (If you want to merge only a subtree, then the subtree path must be included in both SOURCE and TARGET_WCPATH; this is discouraged, to avoid subtree mergeinfo.) SOURCE is usually a URL. The optional '@REV' specifies both the peg revision of the URL and the latest revision that will be considered for merging; if REV is not specified, the HEAD revision is assumed. If SOURCE is a working copy path, the corresponding URL of the path is used, and the default value of 'REV' is the base revision (usually the revision last updated to). TARGET_WCPATH is a working copy path; if omitted, '.' is generally assumed. There are some special cases: - If SOURCE is a URL: - If the basename of the URL and the basename of '.' are the same, then the differences are applied to '.'. Otherwise, if a file with the same basename as that of the URL is found within '.', then the differences are applied to that file. In all other cases, the target defaults to '.'. - If SOURCE is a working copy path: - If the source is a file, then differences are applied to that file (useful for reverse-merging earlier changes). Otherwise, if the source is a directory, then the target defaults to '.'. In normal usage the working copy should be up to date, at a single revision, with no local modifications and no switched subtrees. - The 'Feature Branch' Merging Pattern - In this commonly used work flow, known also as the 'development branch' pattern, a developer creates a branch and commits a series of changes that implement a new feature. The developer periodically merges all the latest changes from the parent branch so as to keep the development branch up to date with those changes. When the feature is complete, the developer performs a merge from the feature branch to the parent branch to re-integrate the changes. parent --+--o--o-o-o-- \\ \ / \ merge merge merge \\ \ / feature +--o-o---oo-oo--- A merge from the parent branch to the feature branch is called a 'sync'
Re: What branching patterns work with Subversion reintegrate merge?
On Mon, Mar 21, 2016 at 02:23:06PM +, Bob Berger wrote: > Thanks for your reply Stefan. It's very much appreciated. > > Before Subversion 1.8 made the reintegrate merge automatic, I was doing > merges without the reintegrate option, which were, I suppose, inappropriate > "complete merges". They were > generally effective, but sometimes produced errors and strange conflicts. > With Subversion 1.8 or higher, I am forced to cherry-pick, which may > sometimes produce poor results if I pick the > wrong cherries. I had regarded cherry-picking as error-prone and something to > be avoided, but it's good to know that it's used successfully elsewhere. > The impression that you're forced to cherry-pick must be a misunderstanding. You can still force the reintegrate merge in 1.8 and later by passing the --reintegrate option. This still works, just as it did in older releases. The option is deprecated because there is no general need for it any more, but it is still available and forces the previous behaviour. I would suggest looking at this problem in terms of a process problem, instead of a Subversion problem. Which kind of merge is most effective depends on the nature and purpose of the branches involved, and details of the overall merge strategy (or "merge pattern"). >From the ASCII diagrams in the svn merge help text you can tell which merge scenario applies to a particular invocation of 'svn merge'. I'd suggest drawing similar diagrams for your own project's workflow, using forked lines to represent branches, solid arrows for complete merges, and dashed arrows for cherry-picks. If you use cherry-picks, writing some example revision numbers below the diagram might help, on a line from left to right, so you can better visualize what will happen in the repository. Then, figure out which svn commands are needed to implement each merge arrow in your workflow. For assistance you could try some merge commands with a toy project in a separate repository to verify Subversion's behaviour matches what you expect. If the diagram becomes too complex to handle with simple Subversion commands, try to simplify your strategy, or use the most general merge invocation (2-URL merges, which can merge anything anywhere), sparingly, where you must.
Re: mod_dav_svn: nested Location '/svn' hinders access to '' in SVNPath Location '/svn'
Manju C wrote on Mon, Mar 21, 2016 at 05:17:01 -0700: > "mod_dav_svn: nested Location '/svn' hinders access to '' in SVNPath > Location '/svn'" It means you have two directives, either two or a and a , that both contain a "DAV svn" directive.
Upgrade Subversion from 1.5 to 1.9
Hi, We have recently taken over a production application from other team, which uses the SVN 1.5.0 as one of the component. Now we have a requirement to upgrade this to latest version of the subversion. While going through the Apache subversion link we have noticed that Subversion 1.9 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7. Is there any workaround to upgrade 1.5.0 to 1.9? Thanks & Regards, Safarulla M.
wc_db.c line 10235: assertion failed
I want to set an external reference to a relative project path, which does not contain spaces (googling the assertion gave a hint that spaces can be involved into creating this assertion). I can enter the path but once I press the context menu entry "Fetch HEAD revision and adjust to it", I get the assertion with the hint (svn_dirent_is_absolute(local_abspath)). The local path is 'XXX', the referenced project is located at '../../../reference_project/trunk/my_src/XXX' and should exist, as a second parallel project which is setup in similar fashion and directory structure can actually reference the same sub-directory. My Tortoise svn is TortoiseSVN 1.9.3, Build 27166 - 64 Bit -dev, 2016/02/08 07:58:04 on Windows 7.
Merging fixes from a branch?
We are using Subversion 1.7. I am trying to document a hotfix methodology. The project has the traditional "TTB" directories. app/trunk app/tags/1.0 app/tags/1.1 app/branches 1.1 is deployed and running in production when a problem occurs. We cannot tag the current trunk and deploy since developers have been making changes and adding features since 1.1 was tagged. It seems that making a branch from app/tags/1.1 to app/branches/1.1_hotfix is the right thing to do. Then, 1.1_hotfix can be checked out, changed, tested, checked back in, and deployed to production. Ok so far? How can the 1.1_hotfix changes be merged back into the trunk? Using 'svn up' does not appear to recognize trunk changes. I assume this is because 1.1_hotfix came from tags/1.1 and not trunk. Is that correct? I am expecting the same problems from 'svn merge' and 'svn merge --reintegrate'. I do -not- want to change tags/1.1 which should remain golden. From the red book: " The second form is called a “reintegrate merge” and is used to bring changes from a feature branch (SOURCE) back into the feature branch's immediate ancestor branch (TARGET_WCPATH)." I am seeking to get the changes back into mainline trunk development. Is this possible? Should I not want to do this? *-*-*- PRESBYTERIAN_HEALTHCARE_SERVICES_DISCLAIMER -*-*-* This message originates from Presbyterian Healthcare Services or one of its affiliated organizations. It contains information, which may be confidential or privileged, and is intended only for the individual or entity named above. It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message. All personal messages express views solely of the sender, which are not to be attributed to Presbyterian Healthcare Services or any of its affiliated organizations, and may not be distributed without this disclaimer. If you received this message in error, please notify us immediately at i...@phs.org. If you would like more information about Presbyterian Healthcare Services please visit our web site http://www.phs.org
Re: Upgrade Subversion from 1.5 to 1.9
> On Mar 21, 2016, at 10:33 AM, Safarulla Meerasahib > wrote: > > Hi, > > We have recently taken over a production application from other team, which > uses the SVN 1.5.0 as one of the component. Now we have a requirement to > upgrade this to latest version of the subversion. > While going through the Apache subversion link we have noticed that > Subversion 1.9 can only upgrade working copies created with Subversion 1.6 > and Subversion 1.7. > Is there any workaround to upgrade 1.5.0 to 1.9? > > Thanks & Regards, > Safarulla M. There is a difference between upgrading the repository and upgrading a working copy. As long as all the code has been committed to the repository, you can simply check out a new working copy using the new client and not be concerned. Upgrading a repository is a not an issue either since the server is quite forward compatible. That said, if your old repository is based on BerkeleyDB you will need to ensure that the new version of SVN is also built to use BDB. Alternatively, you can perform "svnadmin dump" on the old repository and use "svnadmin load" on the new to transform your repository regardless of the storage method. So, make sure you understand the difference between a repository and a working copy.
Re: Upgrade Subversion from 1.5 to 1.9
On Mon, Mar 21, 2016 at 10:33:49AM -0700, Safarulla Meerasahib wrote: > Hi, > > > > We have recently taken over a production application from other team, which > uses the SVN 1.5.0 as one of the component. Now we have a requirement to > upgrade this to latest version of the subversion. > > While going through the Apache subversion link we have noticed that > Subversion 1.9 can only upgrade working copies created with Subversion 1.6 > and Subversion 1.7. > > Is there any workaround to upgrade 1.5.0 to 1.9? Use 'svn checkout' to get new working copies after upgrading. Note that working copies are only used by the Subversion client. A 1.9 server is fully backwards compatible to repositories created by any version of Subversion. If you are unsure about the differences between working copies and repositories, please read this page: http://svnbook.red-bean.com/nightly/en/svn.basic.version-control-basics.html
Re: Merging fixes from a branch?
On Mon, Mar 21, 2016 at 03:44:43PM +, Watson, Paul wrote: > We are using Subversion 1.7. I am trying to document a hotfix methodology. > The project has the traditional "TTB" directories. > > app/trunk > app/tags/1.0 > app/tags/1.1 > app/branches > > 1.1 is deployed and running in production when a problem occurs. We cannot > tag the current trunk and deploy since developers have been making changes > and adding features since 1.1 was tagged. Was /tags/1.1 copied from /trunk? What we do in the Subversion project itself is to copy /trunk to /branches/1.x, and then create tags of our releases made from this branch by copying the branch to /tags/1.0, /tags/1.1, etc. > It seems that making a branch from app/tags/1.1 to app/branches/1.1_hotfix is > the right thing to do. Then, 1.1_hotfix can be checked out, changed, tested, > checked back in, and deployed to production. Ok so far? Yes, that would work, too. Though generally it's slightly more convenient to copy trunk->branch->tag because then all merges interact with trunk and the branch, and don't cross any tags. > How can the 1.1_hotfix changes be merged back into the trunk? Using 'svn up' > does not appear to recognize trunk changes. I assume this is because > 1.1_hotfix came from tags/1.1 and not trunk. Is that correct? Use 'svn merge -c' (cherry pick) to merge from trunk to release branch or vice versa. See 'svn help merge' for more details. I'm quoting the output of svn help merge 1.9 below. > I am expecting the same problems from 'svn merge' and 'svn merge > --reintegrate'. I do -not- want to change tags/1.1 which should remain > golden. >From the red book: > > " The second form is called a “reintegrate merge” and is used to bring > changes from a feature branch (SOURCE) back into the feature > branch's immediate ancestor branch (TARGET_WCPATH)." The reintegrate merge is used with feature branches, not release branches. Perhaps if you read all of the following, things will become more clear. Look at the reintegrate and cherry picking examples, in particular, to see the difference between these two kinds of merges. $ svn help merge merge: Merge changes into a working copy. usage: 1. merge SOURCE[@REV] [TARGET_WCPATH] (the 'complete' merge) 2. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [TARGET_WCPATH] (the 'cherry-pick' merge) 3. merge SOURCE1[@REV1] SOURCE2[@REV2] [TARGET_WCPATH] (the '2-URL' merge) 1. This form, with one source path and no revision range, is called a 'complete' merge: svn merge SOURCE[@REV] [TARGET_WCPATH] The complete merge is used for the 'sync' and 'reintegrate' merges in the 'feature branch' pattern described below. It finds all the changes on the source branch that have not already been merged to the target branch, and merges them into the working copy. Merge tracking is used to know which changes have already been merged. SOURCE specifies the branch from where the changes will be pulled, and TARGET_WCPATH specifies a working copy of the target branch to which the changes will be applied. Normally SOURCE and TARGET_WCPATH should each correspond to the root of a branch. (If you want to merge only a subtree, then the subtree path must be included in both SOURCE and TARGET_WCPATH; this is discouraged, to avoid subtree mergeinfo.) SOURCE is usually a URL. The optional '@REV' specifies both the peg revision of the URL and the latest revision that will be considered for merging; if REV is not specified, the HEAD revision is assumed. If SOURCE is a working copy path, the corresponding URL of the path is used, and the default value of 'REV' is the base revision (usually the revision last updated to). TARGET_WCPATH is a working copy path; if omitted, '.' is generally assumed. There are some special cases: - If SOURCE is a URL: - If the basename of the URL and the basename of '.' are the same, then the differences are applied to '.'. Otherwise, if a file with the same basename as that of the URL is found within '.', then the differences are applied to that file. In all other cases, the target defaults to '.'. - If SOURCE is a working copy path: - If the source is a file, then differences are applied to that file (useful for reverse-merging earlier changes). Otherwise, if the source is a directory, then the target defaults to '.'. In normal usage the working copy should be up to date, at a single revision, with no local modifications and no switched subtrees. - The 'Feature Branch' Merging Pattern - In this commonly used work flow, known also as the 'development branch' pattern, a developer creates a branch and commits a series of changes that implement a new feature. The developer periodically merges
Re: Upgrade Subversion from 1.5 to 1.9
Stefan Sperling wrote on Mon, Mar 21, 2016 at 20:58:37 +0100: > On Mon, Mar 21, 2016 at 10:33:49AM -0700, Safarulla Meerasahib wrote: > > Hi, > > > > > > > > We have recently taken over a production application from other team, > > which uses the SVN 1.5.0 as one of the component. Now we have a requirement > > to upgrade this to latest version of the subversion. > > > > While going through the Apache subversion link we have noticed that > > Subversion 1.9 can only upgrade working copies created with Subversion 1.6 > > and Subversion 1.7. > > > > Is there any workaround to upgrade 1.5.0 to 1.9? > > Use 'svn checkout' to get new working copies after upgrading. > Note that working copies are only used by the Subversion client. For working copies, you can instead first install 1.6 or 1.7, upgrade all working copies, then install 1.9 and upgrade them again. There are still various restrictions, such as [1], so be sure to read the release notes for all intermediate versions (1.6 through 1.9 inclusive). Cheers, Daniel [1] http://subversion.apache.org/docs/release-notes/1.7#wc-upgrade
Re: Upgrade Subversion from 1.5 to 1.9
On Mon, Mar 21, 2016 at 3:58 PM, Stefan Sperling wrote: > On Mon, Mar 21, 2016 at 10:33:49AM -0700, Safarulla Meerasahib wrote: >> Hi, >> >> >> >> We have recently taken over a production application from other team, which >> uses the SVN 1.5.0 as one of the component. Now we have a requirement to >> upgrade this to latest version of the subversion. >> >> While going through the Apache subversion link we have noticed that >> Subversion 1.9 can only upgrade working copies created with Subversion 1.6 >> and Subversion 1.7. >> >> Is there any workaround to upgrade 1.5.0 to 1.9? > > Use 'svn checkout' to get new working copies after upgrading. > Note that working copies are only used by the Subversion client. It can be much safer to designate a second server with a fresh copy of the new version of Subversion, Subverison 1.9 if available, to create a slave of the original repository. This leave the original repository usable until the final switchover It's especially if the repository has gotten large, over time, with binary commits and many branches. Then, when ready to switchover, make a good backup of the old system, *LOCK IT* to prevent any further ocmmits, and switch services to the new server. You should be able to activate a proxy or port forwarding for the old service, if needed, so anyone who accidentally tries to reach the old one actually gets the new one. > A 1.9 server is fully backwards compatible to repositories created > by any version of Subversion. > > If you are unsure about the differences between working copies and > repositories, please read this page: > http://svnbook.red-bean.com/nightly/en/svn.basic.version-control-basics.html
RE: Merging fixes from a branch?
> -Original Message- > From: Watson, Paul [mailto:pwat...@phs.org] > Sent: 21 March 2016 15:45 > > We are using Subversion 1.7. I am trying to document a hotfix methodology. > The project has the traditional "TTB" directories. > > app/trunk > app/tags/1.0 > app/tags/1.1 > app/branches > > 1.1 is deployed and running in production when a problem occurs. We cannot > tag the current trunk and deploy since developers have been making changes > and adding features since 1.1 was tagged. > > It seems that making a branch from app/tags/1.1 to app/branches/1.1_hotfix is > the right thing to do. Then, 1.1_hotfix can be checked out, changed, tested, > checked back in, and deployed to production. Ok so far? Alternatively you could "recreate" the missing trunk->branch->tag branch by copying the tag's original source revision of trunk to a new branch and working on that. Then you will also be able to merge you changes back to trunk. ~ Mark C > How can the 1.1_hotfix changes be merged back into the trunk? Using 'svn up' > does not appear to recognize trunk changes. I assume this is because > 1.1_hotfix came from tags/1.1 and not trunk. Is that correct? > > I am expecting the same problems from 'svn merge' and 'svn merge -- > reintegrate'. I do -not- want to change tags/1.1 which should remain golden. > From the red book: > > " The second form is called a “reintegrate merge” and is used to bring > changes from a feature branch (SOURCE) back into the feature > branch's immediate ancestor branch (TARGET_WCPATH)." > > I am seeking to get the changes back into mainline trunk development. Is this > possible? Should I not want to do this?
