Re: weird merge
On Mar 31, 2010, at 03:31, Cooke, Mark wrote: On Mar 30, 2010, at 18:55, Xavier Noria wrote: Can I tell to svn that it totally forget revisions 3000 ? Doing so is a very invasive procedure. I don't recommend it. It's likely to cause more problems than it solves. Those are very old and we could just get rid of them it there was a chance that it solved the issue, it is a pity we need to deal with explicit revisions all the time, reflective merges... I don't know, perhaps around r2909 people did something with the repo, upgrading, ... no idea. What about doing an svnadmin dump -r 3000:head of the repository starting at r3000, then load that in to a new repo and use that? I believe it should dump enough info to build 3000 then increment from there. However, I've never tried it. http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.rep osadmin.maint.filtering Yes, that is the procedure I am talking about. It is very invasive, because it necessitates all users throwing away all working copies and checking them out again, means all old revision numbers (e.g. that have been recorded in issue tracker ticket notes, documentation, etc.) are no longer accurate, and does not necessarily result in space savings in the repository, which is what many people are looking for when they consider this procedure. (It may even increase the repository's size.) Remember to keep the discussion on the list by using Reply All.
XML output for svnlook
I'm using Subversion 1.6.9 and I noticed that svnlook changed does not have an option for XML output. Before filing a request for this, I would like to see if there is any support on the list. Regards, Giulio Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851VAT Reg No 778499447
RE: weird merge
On Mar 31, 2010, at 03:31, Cooke, Mark wrote: On Mar 30, 2010, at 18:55, Xavier Noria wrote: Can I tell to svn that it totally forget revisions 3000 ? Doing so is a very invasive procedure. I don't recommend it. It's likely to cause more problems than it solves. Those are very old and we could just get rid of them it there was a chance that it solved the issue, it is a pity we need to deal with explicit revisions all the time, reflective merges... I don't know, perhaps around r2909 people did something with the repo, upgrading, ... no idea. What about doing an svnadmin dump -r 3000:head of the repository starting at r3000, then load that in to a new repo and use that? I believe it should dump enough info to build 3000 then increment from there. However, I've never tried it. http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.rep osadmin.maint.filtering Yes, that is the procedure I am talking about. It is very invasive, because it necessitates all users throwing away all working copies and checking them out again, means all old revision numbers (e.g. that have been recorded in issue tracker ticket notes, documentation, etc.) are no longer accurate, and does not necessarily result in space savings in the repository, which is what many people are looking for when they consider this procedure. (It may even increase the repository's size.) I thought there was a way to persuade svnadmin load to keep the revision numbers but on looking I cannot find anything. It seems to renumber revs by default. However, I have a repository that I created from a VSS conversion and used dumpfilter on and the revisions start at 282, so it must be possible somehow... Working copies can be relocated (if you keep the same repo UUID) but I believe that the renumbered revisions would still be a show stopper. I'm confused now! Remember to keep the discussion on the list by using Reply All. Dang, thanks for the reminder. ~ Mark C
RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?!
Thank you very much for that helping link! This is exactly the type of background information I've been looking for. With the help of your linked article, if found out that on the root directory a mergeinfo was set. I tried to removed the existing property as workaround on both trunk branch. Unfortunately I still receive explicit entries mergeinfo entries following this scheme on totally unrelated paths (no relevant commit since branch-off): Added: svn:mergeinfo Merged /branches/1.1.x/tools/releasenotes:r3101-3122* Added: svn:mergeinfo Merged /branches/1.1.x/tools/releasenotes/axis-jaxrpc-1.3.jar:r3101-3122 Any hint on where those do origin from? Are those issues adressed by svn 1.7.x? The mentioned articel did not provide any explanation pattern for me. Cheers! - Ben -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, March 30, 2010 12:21 PM I don't have time right now to analyze and explain your particular situation, but as for a link to detailed background information, you might want to read this article: http://www.collab.net/community/subversion/articles/merge-info.html Also, if I understood correctly, improvements are being made in this area for svn 1.7 (for starters, in 1.7 only subtrees affected by the merge will have their mergeinfo updated). But it's too early to tell how that will work out. Svn 1.7 is still at least a couple of months away... -- Johan
RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?!
In addition to adding merge info to your working copy target, merge info will be added to any file or folder under a target folder if the file or folder already has an svn:mergeinfo property. This will happen even if the original svn:mergeinfo property is empty. The only way to correct this is to consolidate the merge info into the root folders of a working copy, and its externals, and to *delete* the svn:mergeinfo property from all child folders and files. To avoid an increasing number of items with this property, as a result of non-root merges or copies, you would have to restrict setting of the svn:mergeinfo property to a root folder. The Subversion Hook Framework can be used to enforce this policy. - http://sourceforge.net/projects/svnhook There's an example of the required configuration (XML) file entry on the Hook Configuration File Examples page of the wiki. - http://sourceforge.net/apps/mediawiki/svnhook/index.php?title=Hook_Configura tion_File_Examples -Geoff -Original Message- From: Ben [mailto:tebu...@googlemail.com] Sent: Wednesday, March 31, 2010 7:48 AM To: users@subversion.apache.org Subject: RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?! Thank you very much for that helping link! This is exactly the type of background information I've been looking for. With the help of your linked article, if found out that on the root directory a mergeinfo was set. I tried to removed the existing property as workaround on both trunk branch. Unfortunately I still receive explicit entries mergeinfo entries following this scheme on totally unrelated paths (no relevant commit since branch-off): Added: svn:mergeinfo Merged /branches/1.1.x/tools/releasenotes:r3101-3122* Added: svn:mergeinfo Merged /branches/1.1.x/tools/releasenotes/axis-jaxrpc-1.3.jar:r3101-3122 Any hint on where those do origin from? Are those issues adressed by svn 1.7.x? The mentioned articel did not provide any explanation pattern for me. Cheers! - Ben -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, March 30, 2010 12:21 PM I don't have time right now to analyze and explain your particular situation, but as for a link to detailed background information, you might want to read this article: http://www.collab.net/community/subversion/articles/merge-info.html Also, if I understood correctly, improvements are being made in this area for svn 1.7 (for starters, in 1.7 only subtrees affected by the merge will have their mergeinfo updated). But it's too early to tell how that will work out. Svn 1.7 is still at least a couple of months away... -- Johan
Re: Out of memory error while merging
On 19 Mar, 13:16, RoboJ1M robo...@gmail.com wrote: Hi, I'm having a problem with our new SVN system. Initially I thought it was a problem with TortoiseSVN but after discussing it on their mailing list and performing the same actions in command line svn it seems the problem further up the pipe. Anyway, I'm getting Out OfMemoryfor this command: svnmerge--non-interactivehttp://xxx/branches/Southwark_PermitsC: \xxx\trunk System information: Server: Ubuntu Server 8.04 svn, version 1.5.1 (r32289) Client: Win XP SP3 32bit 4GB (3.25GB available) of RAM svn, version 1.6.9 (r901367) compiled Jan 21 2010, 22:00:47 Previous thread at TSVN:http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061dsMess... I've tested tortoise on two machines, a clean check out andmerge fails (testmergesucceeds) Command line test succeeds on my machine. I know that's not a lot of information to go on, but if somebody can show me how to get more info out of svn I can post it. Many Thanks, James. Hi, Further to my original post I have reposted this on the svn-developers list in hope of getting the route cause fixed. I have also tested the merge on the Ubuntu server itself, where it works perfectly. However I am concerned about checking out and merging on Ubuntu, copying to Windows, completing the merge by fixing conflicts and testing the code before commiting it back on either the Windows machine or Ubuntu machine. Can I do that? Is it safe? Thanks, James.
svn stat - show source of copied files
I'm trying to determine the source of an added file after rename, for example, prior the changes are committed. Is it possible? I have not been able to find out how using the stat command. All I get is the + indicator: svn stat A +path/to/myfile D myfile FWIW, I've seen this with the Mercurial's stat command: hg stat A path/to/myfile R myfile hg stat -C A path/to/myfile myfile R myfile -- Stanimir
RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?! -- SOLVED !!!
Geoff - Thank you very much for your extensive advice of how to avoid these problems! We'll definitly implement your hint regarding a subversion hook. My problem was not any existing svn:mergeinfos. Neither the source nor the target contained *any* svn:mergeinfo except one at the target root. But I finally found the solution! My problem was: *svnversion reported 3128P* I have no clue how this occured. We *never* do partial chechkouts, but a short poll at my collegues showed, that many of them having this situation, too! After recovering the partial state all works as expected. Thanks a lot to everybody for your time and support! - Ben -Original Message- From: Geoff Rowell [mailto:geoff.row...@gmail.com] Sent: Wednesday, March 31, 2010 2:56 PM To: 'Ben' Cc: users@subversion.apache.org Subject: RE: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?! In addition to adding merge info to your working copy target, merge info will be added to any file or folder under a target folder if the file or folder already has an svn:mergeinfo property. This will happen even if the original svn:mergeinfo property is empty. The only way to correct this is to consolidate the merge info into the root folders of a working copy, and its externals, and to *delete* the svn:mergeinfo property from all child folders and files. To avoid an increasing number of items with this property, as a result of non-root merges or copies, you would have to restrict setting of the svn:mergeinfo property to a root folder. The Subversion Hook Framework can be used to enforce this policy. - http://sourceforge.net/projects/svnhook There's an example of the required configuration (XML) file entry on the Hook Configuration File Examples page of the wiki. - http://sourceforge.net/apps/mediawiki/svnhook/index.php?title=Hook_Confi gura tion_File_Examples -Geoff
Re: svn stat - show source of copied files
On Wed, Mar 31, 2010 at 05:09:08PM +0300, Stanimir Stamenkov wrote: I'm trying to determine the source of an added file after rename, for example, prior the changes are committed. Is it possible? Yes, you can use svn info: $ svn info alpha.copy Path: alpha.copy Name: alpha.copy URL: file:///tmp/svn-sandbox/repos/trunk/alpha.copy Repository Root: file:///tmp/svn-sandbox/repos Repository UUID: b8590abe-3cd0-11df-a5c1-e3980ec03287 Revision: 2 Node Kind: file Schedule: add Copied From URL: file:///tmp/svn-sandbox/repos/trunk/alpha Copied From Rev: 2 ^^ Checksum: 9f9f90dbe3e5ee1218c86b8839db1995 Stefan
RE: svnadmin create not honoring sticky bit
Hi, users-return-1912-ullrich.jans=elektrobit@subversion.apach e.org wrote: Subject: RE: svnadmin create not honoring sticky bit Stefan Sperling wrote: On Tue, Mar 30, 2010 at 02:16:50PM +0200, ullrich.j...@elektrobit.com wrote: ls -l test1/db/rep-cache.db test2/db/rep-cache.db -rw-r-+ 1 root www 4096 2010-03-30 14:07 test1/db/rep-cache.db -rw-r-+ 1 username users 4096 2010-03-30 14:07 test2/db/rep-cache.db See http://subversion.tigris.org/issues/show_bug.cgi?id=3437 I know about that one. (That's why I mentioned it in my original mail) What's new (to me) is the permissions on *all* the files in db (just one example from db to keep the email short): drwxrws---+ 3 root www 4096 2010-03-30 14:07 test1/db/revs drwxrwx---+ 3 username users 4096 2010-03-30 14:07 test2/db/revs Looking at the main directory shows that the sticky bit on db got dropped: ls -l test2 total 48 drwxrws---+ 2 username www 4096 2010-03-30 14:07 conf drwxrwx---+ 6 username www 4096 2010-03-30 14:07 db ^here -r--r-+ 1 username www2 2010-03-30 14:07 format drwxrws---+ 2 username www 4096 2010-03-30 14:07 hooks drwxrws---+ 2 username www 4096 2010-03-30 14:07 locks -rw-rw+ 1 username www 229 2010-03-30 14:07 README.txt Occurred on svn 1.6.9 (package from the Suse Buildservice): subversion-1.6.9-4.3 subversion-perl-1.6.9-4.3 subversion-tools-1.6.9-4.3 subversion-server-1.6.9-4.3 Any ideas on that one? Should I open an issue in the tracker? Cheers, Ulli Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you.
One commit two repositories
During an audit we found a one commit pushed files from one folder into two repositories. The commit occurred following a successful switch. It appears the switch was still running in the background so files were split across the two branches. Does anyone have an explanation? I am using TortoiseSVN version: TortoiseSVN 1.6.6, Build 17493 - 32 Bit , 2009/10/19 20:22:18 Subversion 1.6.6, apr 1.3.8 apr-utils 1.3.9 neon 0.28.6 OpenSSL 0.9.8k 25 Mar 2009 zlib 1.2.3 Here is the list of files committed under revision 3585: /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/EntityComponents.cls /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/MiniPair.cls /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/MiniPairConfiguration.bas /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/minipairProgress.frm /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/MiniPairTool.vbp /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/MiniPairTool.vbw /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/oosTranslations.cls /ptr/44635/MSDE_AAR/OneSAF/Common/src/MiniPairTool/UDBData.cls /ptr/44696/MSDE_AAR/OneSAF/Common/src/MiniPairTool/commonWarfightingSymbology.cls Jeff ***This e-mail message is intended only for the above named recipient(s) and may contain information that is sensitive or proprietary. If you have received this message in error or are not the named recipient(s), please immediately notify the sender, delete this e-mail message without making a copy and do not disclose or relay this e-mail message to anyone.***
Re: Spurious svn:mergeinfo updated on random, untouched files on minimalistic merge?! -- SOLVED !!!
Wed, 31 Mar 2010 16:22:37 +0200, /Ben/: My problem was not any existing svn:mergeinfos. Neither the source nor the target contained *any* svn:mergeinfo except one at the target root. But I finally found the solution! My problem was: *svnversion reported 3128P* I have no clue how this occured. We *never* do partial chechkouts, but a short poll at my collegues showed, that many of them having this situation, too! After recovering the partial state all works as expected. Ben, I haven't got what your actual problem was. You've stated you didn't have svn:mergeinfo on files and folders below the root. What does svnversion reported 3128P mean? -- Stanimir
LDAP Group Configuration in AuthzSVNAccessFile
I have been set the task of setting up SVN and connecting Authentication and Authorization to our MS Active Directory system. The SVN is now running on a Debian Linux server. I have successfully set up Authenticated to authenticate users who have access to the SVN system based on a Security Group in our AD. The next task is where I am encountering the difficulty is in Authorizing individual users to read and write to the individual repositories. From what I have seen I need I to do this I need a AuthzSVNAccessFile file. However I have not been able to find any documentation on how to accomplish this using AD groups. Below is a simple example. Let the following users exist. UserA, UserB, UserC, UserD. Let the following user groups exist. canAccessSVN, canOnlyReadReop1, canReadWriteReop1, canOnlyReadReop2, canReadWriteReop2. Users UserA, UserB, and UserC In group canAccessSVN. Let the following SVN repositories exist. (repo1, repo2, sandbox). UserA is in groups canAccessSVN, canReadWriteReop1, canReadWriteReop2. UserB is in groups canAccessSVN, canReadWriteReop1. UserC is in group canAccessSVN, canReadWriteReop2, canOnlyReadReop1. UserD has access to nothing (this part I have solved using the canAccessSVN in the dav_svn.conf file. All users should have Read and Write access to the sandbox repository, UserA should have Read and Write access to both reop1 and repo2 and sandbox. UserB should have Read and Write access to only repo1. UserC should have Read and Write to repo2, and read access to repo1. The trick is I want to do this with the AD groups. I have searched and have not found any reference do controlling this with AD groups in the AuthzSVNAccessFile file. Any help or pointers to a reference would be very helpful. Lee
Re: LDAP Group Configuration in AuthzSVNAccessFile
On Wed, Mar 31, 2010 at 12:23 PM, Lee Kaufman lee.kauf...@transmetric.com wrote: I have been set the task of setting up SVN and connecting Authentication and Authorization to our MS Active Directory system. The SVN is now running on a Debian Linux server. I have successfully set up Authenticated to authenticate users who have access to the SVN system based on a Security Group in our AD. The next task is where I am encountering the difficulty is in Authorizing individual users to read and write to the individual repositories. From what I have seen I need I to do this I need a AuthzSVNAccessFile file. However I have not been able to find any documentation on how to accomplish this using AD groups. Below is a simple example. Last time I checked, you can't do authorization via LDAP/AD. Just authentication. Hence the lack of documentation on the subject. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin carpe diem quam minimum credula postero
Re: LDAP Group Configuration in AuthzSVNAccessFile
On Wed, Mar 31, 2010 at 12:40:13PM -0700, Aaron Turner wrote: On Wed, Mar 31, 2010 at 12:23 PM, Lee Kaufman lee.kauf...@transmetric.com wrote: I have been set the task of setting up SVN and connecting Authentication and Authorization to our MS Active Directory system. The SVN is now running on a Debian Linux server. I have successfully set up Authenticated to authenticate users who have access to the SVN system based on a Security Group in our AD. The next task is where I am encountering the difficulty is in Authorizing individual users to read and write to the individual repositories. From what I have seen I need I to do this I need a AuthzSVNAccessFile file. However I have not been able to find any documentation on how to accomplish this using AD groups. Below is a simple example. Last time I checked, you can't do authorization via LDAP/AD. Just authentication. Hence the lack of documentation on the subject. Various wrapper scripts exist which generate an authz rules file from data pulled from LDAP/AD directories. I agree that it would be nice to have built-in support for this in mod_authz_svn though. Stefan
Re: LDAP Group Configuration in AuthzSVNAccessFile
On Wed, Mar 31, 2010 at 2:25 PM, Stefan Sperling s...@elego.de wrote: On Wed, Mar 31, 2010 at 12:40:13PM -0700, Aaron Turner wrote: On Wed, Mar 31, 2010 at 12:23 PM, Lee Kaufman lee.kauf...@transmetric.com wrote: I have been set the task of setting up SVN and connecting Authentication and Authorization to our MS Active Directory system. The SVN is now running on a Debian Linux server. I have successfully set up Authenticated to authenticate users who have access to the SVN system based on a Security Group in our AD. The next task is where I am encountering the difficulty is in Authorizing individual users to read and write to the individual repositories. From what I have seen I need I to do this I need a AuthzSVNAccessFile file. However I have not been able to find any documentation on how to accomplish this using AD groups. Below is a simple example. Last time I checked, you can't do authorization via LDAP/AD. Just authentication. Hence the lack of documentation on the subject. Various wrapper scripts exist which generate an authz rules file from data pulled from LDAP/AD directories. I agree that it would be nice to have built-in support for this in mod_authz_svn though. Do you have a link to such a script? I've occasionally looked for one and never found it... was planning on writing one someday, but no point in reinventing the wheel. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin carpe diem quam minimum credula postero
Re: LDAP Group Configuration in AuthzSVNAccessFile
On Wed, Mar 31, 2010 at 02:28:53PM -0700, Aaron Turner wrote: On Wed, Mar 31, 2010 at 2:25 PM, Stefan Sperling s...@elego.de wrote: On Wed, Mar 31, 2010 at 12:40:13PM -0700, Aaron Turner wrote: On Wed, Mar 31, 2010 at 12:23 PM, Lee Kaufman lee.kauf...@transmetric.com wrote: I have been set the task of setting up SVN and connecting Authentication and Authorization to our MS Active Directory system. The SVN is now running on a Debian Linux server. I have successfully set up Authenticated to authenticate users who have access to the SVN system based on a Security Group in our AD. The next task is where I am encountering the difficulty is in Authorizing individual users to read and write to the individual repositories. From what I have seen I need I to do this I need a AuthzSVNAccessFile file. However I have not been able to find any documentation on how to accomplish this using AD groups. Below is a simple example. Last time I checked, you can't do authorization via LDAP/AD. Just authentication. Hence the lack of documentation on the subject. Various wrapper scripts exist which generate an authz rules file from data pulled from LDAP/AD directories. I agree that it would be nice to have built-in support for this in mod_authz_svn though. Do you have a link to such a script? I've occasionally looked for one and never found it... was planning on writing one someday, but no point in reinventing the wheel. Google svn authz ldap says: http://www.thoughtspark.org/node/26 This patch to apache httpd also looks interesting: http://mail-archives.apache.org/mod_mbox/httpd-dev/200912.mbox/%3c4b22cfbe@gmx.net%3e Though I didn't check what became of it. Stefan
RE: subscribing
I'm having trouble subscribing. if there's a trick please let me know. I sent mail to users-subscribe with just 'subscribe j...@zeevee.com' in the body no answer. You are sending an email to users-subscr...@subversion.apache.org ? No subject no body? We use a lot of project branches, that is, we branch from trunk, develop a feature and then merge it back to trunk. Quite often, we need to merge a change or two from trunk out to our branch along the way. What I have noticed is that when I go to merge the branch back to trunk, the changes that were merged from trunk to the branch are included when I do a 'svn mergeinfo --show-revs eligible branchname trunk'. Why is this? Shouldn't the system know that these were merged out and therefore do not need to be merged in? I do not ever use 'ignore-ancestry'. I end up doing a lot of 'svn merge --record-only's to block the reverse merges. If you have a feature branch you should be merging from trunk into the branch regularly. then when you are done with the feature you would do a reintegrate merge back. I don't see an argument on merginfo to specify that you want to do a re-integrate. BOb
Multiple Lines for groups in authz conf file
I'm using mod_authz to specify permissions in svn. Is there a way to list the group members on multiple lines instead of just a single line? For example, instead of: [groups] developers=joe, frank, bob I would like to have something like: [groups] developers= joe, frank, bob Will this work? The reason is that one of the groups is very large, and it's messy to have all the users on one line. Thanks!
Re: subscribing
2010/4/1 Bob Archer bob.arc...@amsi.com: I'm having trouble subscribing. if there's a trick please let me know. I sent mail to users-subscribe with just 'subscribe j...@zeevee.com' in the body no answer. You are sending an email to users-subscr...@subversion.apache.org ? No subject no body? See note about spam filters here: http://www.apache.org/foundation/mailinglists.html Best regards, Konstantin Kolinko
