Problem with subversion-perl RPMs from WanDisco?
Hi all, I tried to update subversion to 1.8.10 on a freshly installed CentOS 6.5 and noticed that an attempt to use Perl bindings has failed due to an undefined symbol in the libsvn_swig_perl library: svn_swig_pl_get_current_pool $ readelf -Ws /tmp/usr/lib64/libsvn_swig_perl-1.so.0 | grep svn_swig_pl_get_ 79: 0 NOTYPE GLOBAL DEFAULT UND svn_swig_pl_get_current_pool This symbol is defined in the library packaged into 1.9.0-alpha2 RPMs, but not in any 1.8.x/1.7.x RPMs. I have also tried on another machin - it originally had CentOS 6.0 installed + partially upgraded. There, the Subversion Perl bindings from WanDisco's RPM just coredump in Repos::Open - I am not sure if it is the same issue or not. It works with the original CentOS version of subversion-perl (1.6.x). Regards, Alexey.
Re: please help me with path-based access control setup
On 10 Sep 2014 20:06, "James" wrote: > > My svnserve is running on Fedora and I can access (checkout, update, ..) with svn://repository/.. without any issue from local machine and another machine. > > I also setup user/password access control. It works great. Now I am trying to add path-based access control on top of it. > > I enabled the "authz-db = authz" on the svnserve.conf file. > I tested with following settings on the authz file: > > #= > #[/home/svn/Playground/proj1] > #[/home/svn/Playground] > #[/home/svn/Playground/] > #[repository:/Playground] > #[repository:/proj1] > [repository:/*] > testuser = rw > $authenticated = rw > * = rw > > but none worked. I always get this error: > svn: E170001: Authorization failed. The the bit before the rule path in the authz file is the repository name, not its local path and not the server name. The rules also cannot contain wildcards. Try: [Playground:/] * = rw -- Brane
Re: please help me with path-based access control setup
Ok, I found what wrong with my authz file's settings after read the svnbook carefully again. Now there is only one thing still doesn't work for me: deny the access of a subdirectory: by follow the example in the svnbook, I have the following setting: #--- [/] superuser = rw #* = r [Playground:/proj1] user1 = rw [Playground:/proj1/trunk/proj1Folder1] user1 = [Playground:/proj2] user2 = rw # suppose the user1 shouldn't have access to the "/proj1/trunk/proj1Folder1" directory. but when I do checkout, that directory is still be checked out to my machine. is that behavor correct? On Wednesday, September 10, 2014 2:05 PM, James wrote: My svnserve is running on Fedora and I can access (checkout, update, ..) with svn://repository/.. without any issue from local machine and another machine. I also setup user/password access control. It works great. Now I am trying to add path-based access control on top of it. I enabled the "authz-db = authz" on the svnserve.conf file. I tested with following settings on the authz file: #= #[/home/svn/Playground/proj1] #[/home/svn/Playground] #[/home/svn/Playground/] #[repository:/Playground] #[repository:/proj1] [repository:/*] testuser = rw $authenticated = rw * = rw but none worked. I always get this error: svn: E170001: Authorization failed. If I disable the "authz-db = authz" on the svnserve.conf file, svn immediately works. My svn repositry is in /home/svn directory. The repository name is Playground. There are two projects there: proj1 and proj2. When I try to do checkout with --username --password option, I was asked for password. After pass the name/password, I received the "svn: E170001: Authorization failed." error. My setting in the authz file is not correct? or I need to change more configurations? thanks, James
please help me with path-based access control setup
My svnserve is running on Fedora and I can access (checkout, update, ..) with svn://repository/.. without any issue from local machine and another machine. I also setup user/password access control. It works great. Now I am trying to add path-based access control on top of it. I enabled the "authz-db = authz" on the svnserve.conf file. I tested with following settings on the authz file: #= #[/home/svn/Playground/proj1] #[/home/svn/Playground] #[/home/svn/Playground/] #[repository:/Playground] #[repository:/proj1] [repository:/*] testuser = rw $authenticated = rw * = rw but none worked. I always get this error: svn: E170001: Authorization failed. If I disable the "authz-db = authz" on the svnserve.conf file, svn immediately works. My svn repositry is in /home/svn directory. The repository name is Playground. There are two projects there: proj1 and proj2. When I try to do checkout with --username --password option, I was asked for password. After pass the name/password, I received the "svn: E170001: Authorization failed." error. My setting in the authz file is not correct? or I need to change more configurations? thanks, James
Re: Merge problem
On Wed, Sep 10, 2014 at 10:56:42AM +, Andreas Tscharner wrote: > > [snip] > > Just wondering if anyone may have an idea how my repository > > got so buggered up. I tried to merge a branch to the trunk > > and received 49 conflicts. 2 are files that do not need to > > be tracked so that leaves 47. Out of the 47 there are two > > problems, local add, incoming add upon merge & local delete, > > incoming delete upon merge. I was doing some code cleanup so > > it is possible I deleted the files in two different branches. > > But I know for certain that I did not create the same file > > twice. I did a diff on the first one and it is identical in > > both branches, easy to fix, difficult to determine how the > > conflict came about. The second file is different, I deleted > > dome code that is not needed anymore. More work to fix. > > With the conflict it causes the merge to fail thus making > > this much more time consuming to fix. The question I have is > > I don't want to offend anyone here, but such bogus merge conflicts were the > reason we changed to git. Apples and oranges. > > > anyone know what I could’ve done to create these false conflicts? > > > Not to my knowledge... Did you ask for help on this list when you got similar conflicts? Any pointers to threads I could read? I'm genuinly interested in what conflicts you were seeing and how you attempted to resolve them. But I need details, handwavy statements won't help me.
RE: Merge problem
[snip] > Just wondering if anyone may have an idea how my repository > got so buggered up. I tried to merge a branch to the trunk > and received 49 conflicts. 2 are files that do not need to > be tracked so that leaves 47. Out of the 47 there are two > problems, local add, incoming add upon merge & local delete, > incoming delete upon merge. I was doing some code cleanup so > it is possible I deleted the files in two different branches. > But I know for certain that I did not create the same file > twice. I did a diff on the first one and it is identical in > both branches, easy to fix, difficult to determine how the > conflict came about. The second file is different, I deleted > dome code that is not needed anymore. More work to fix. > With the conflict it causes the merge to fail thus making > this much more time consuming to fix. The question I have is I don't want to offend anyone here, but such bogus merge conflicts were the reason we changed to git. > anyone know what I could’ve done to create these false conflicts? > Not to my knowledge... Best regards WENZEL Metromec AG Andreas -- Andreas Tscharner, Development WENZEL Metromec AG, Rheinfelsstrasse 1, CH-7007 Chur, Switzerland phone: +41 (0)81 257 07 00 fax:+41 (0)81 257 07 01 e-mail: mailto:andreas.tschar...@metromec.ch www:http://www.metromec.ch
Re: Merge problem
On Tue, Sep 09, 2014 at 06:48:31PM +, John Maher wrote: > Hello > > Just wondering if anyone may have an idea how my repository got so buggered > up. I tried to merge a branch to the trunk and received 49 conflicts. 2 are > files that do not need to be tracked so that leaves 47. Out of the 47 there > are two problems, local add, incoming add upon merge & local delete, incoming > delete upon merge. I was doing some code cleanup so it is possible I deleted > the files in two different branches. But I know for certain that I did not > create the same file twice. I did a diff on the first one and it is > identical in both branches, easy to fix, difficult to determine how the > conflict came about. The second file is different, I deleted dome code that > is not needed anymore. More work to fix. With the conflict it causes the > merge to fail thus making this much more time consuming to fix. The question > I have is anyone know what I could've done to create these false conflicts? > What are the parameters you used to run this merge? At first glance this looks like your merge source and target are at non-corresponding levels in the tree, e.g. as if you merged from ^/branches/mybranch to ^/trunk/some/subdir/of/trunk > Result of the merge: > --- Merging r222 through r235 into '.': >C RotairAO_SupplierManufacturer\SupplierManufacturerTranslate.vb >C RotairAO_SupplierManufacturer\SupplierManufacturerController.vb >C IntuitiveUI_ItemCard_CUSTOM\CopyItem.vb >C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.resx >C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.designer.vb >C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.vb >C IntuitiveUI_ItemCard_CUSTOM\ItemCard.resx >C IntuitiveUI_ItemCard_CUSTOM\CopyItem.resx >C IntuitiveUI_ItemCard_CUSTOM\ItemCard.Designer.vb >C IntuitiveUI_ItemCard_CUSTOM\CopyItem.Designer.vb >C IntuitiveUI_ItemCard_CUSTOM\ItemCard.vb >C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.Designer.vb >C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.vb >C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.resx >C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.resx >C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.Designer.vb >C IntuitiveUI_ItemCard_CUSTOM\UI_CreateItemRev_CUSTOM.vb >C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.Designer.vb >C IntuitiveUI_ItemCard_CUSTOM\UI_CopyItem_CUSTOMx.vb >C IntuitiveUI_ItemCard_CUSTOM\UI_ItemCard_CUSTOM.resx > AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.resx > AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.Designer.vb > AIntuitiveUI_SalesOrder_CUSTOM\SalesOrder.vb >C RotairUI_SupplierManufacturer\app.config >C Rotair_Excel\Schema.resx >C Rotair_Excel\Schema.Designer.vb >C Rotair_Excel\Schema.vb >C RotairAO_RFQ\RFQVendorCharge.vb > ARotairAO_RFQ\RFQImaging OLD.vb >C RotairAO_RFQ\RFQVendorQuote.vb >C RotairAO_RFQ\RFQImagingController.vb > ARotairAO_RFQ\RFQUnindexed OLD.vb >C RotairAO_RFQ\RFQsEmailed.vb >C RotairAO_RFQ\RFQUnindexedController.vb >C RotairAO_RFQ\RFQMaster.vb >C RotairAO_RFQ\RFQVendor.vb >C RotairAO_RFQ\RFQItemQuantity.vb >C RotairAO_RFQ\RFQItem.vb >C RotairAO_RFQ\IO.vb >C Rotair_System\File.vb > --- Merging r222 through r235 into 'RotairUI_Email': >C RotairUI_Email\NewMessage.Designer.vb >C RotairUI_Email\NewMessage.vb >C RotairUI_Email\NewMessage.resx > --- Merging r222 through r235 into '.': >C RotairUI_RFQ\UnenteredVendorDialog.resx >C RotairUI_RFQ\Resources >C RotairUI_RFQ\UnenteredVendorDialog.Designer.vb >C RotairUI_RFQ\UnenteredVendorDialog.vb >C RotairUI_RFQ\RotairUI_RFQ.vbproj.user >C RotairUI_RFQ\RotairUI_RFQ.suo >C RotairDataAccess\DomainWorkOrder.vb >C RotairDataAccess_Wrapper\DomainShipping.vb >C RotairDialog_Screening\SelectVendor.Designer.vb >C RotairDialog_Screening\SelectVendor.vb >C RotairDialog_Screening\SelectVendor.resx > --- Recording mergeinfo for merge of r222 through r235 into '.': > U . > --- Recording mergeinfo for merge of r222 through r235 into 'RotairUI_Email': > U RotairUI_Email > Summary of conflicts: > Tree conflicts: 49 > > Status of the files: > C IntuitiveUI_ItemCard_CUSTOM\CreateItemRev.vb > > local add, incoming add upon merge > Summary of conflicts: > Tree conflicts: 1 > C IntuitiveUI_ItemCard_CUSTOM\ItemCard.resx > > local add, incoming add upon merge > Summary of conflicts: > Tree conflicts: 1 > C IntuitiveUI_ItemCard_CUSTOM\CopyItem.resx > > local add, incoming add upon merge > Summary of conflicts: > Tree conflicts: 1 > C IntuitiveUI_ItemCard_CUSTOM\ItemCard.Designer.vb > > local add, incoming add upon merge > Summary of conflicts: > Tree conflicts: 1 > C IntuitiveUI_ItemCard_CUSTOM\CopyItem.Designer.vb > > local add, incoming add upon merge > Summary of conflicts: > Tree conflicts: 1 > C
