Re: Subversion upgrade from 1.5 to 1.6
Hello, I agree that dump/restore is the best option but in some cases, a repository may be so large that dump/restore is unpratical. The "svnadmin upgrade" command is a minimal operation to do but your repository structure will not be sharded (if it comes from 1.4 for instance). My preference is: - backup with .tar.gz - svnadmin upgrade to enable 1.6 features - my own version fsfs-reshard can reshard/unpack from 1.3 to 1.6 versions (I have post it here few weeks ago with how to) - svnadmin verify That's all and it has not consumed three time disk space and 2 hours of CPU ! The fsfs-reshard script is not necessary but your repository may stay in "linear" mode instead of the more efficient "sharded" mode. This script also helps you tweak the shard size to improve disk-access performance (mostly on windows or over SAN) Kind regards -- Yves Martin
Reintegrate merge to another branch
Hi SVN folks! We are using Tortoise reintegrate successfully to merge changes back to the branch that have been used for branch-off. But if we are using reintegrate to apply the same differences to another branch, we are getting bad merge results. Is there a bug-fix for that problem available or is it only possible to do that merge using range-merging? Environment --- Win32-Client svn, version 1.6.11 (r934486) compiled Apr 16 2010, 10:39:09 TortoiseSVN 1.6.8, Build 19260 - 32 Bit , 2010/04/16 20:20:11 Subversion 1.6.11, apr 1.3.8 apr-utils 1.3.9 neon 0.29.3 OpenSSL 0.9.8k 25 Mar 2009 zlib 1.2.3 Linux Server: svn, version 1.6.6 - Best Regards, Andreas Graf .. Confidentiality Notice The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company. If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it. .
RE: Reintegrate merge to another branch
I don't think is possible to use --reintegrate. You can always to a "old style" merge with a revision range. But there is something I don't understand. I presume you have created both branches from trunk, so after you have reintegrated the first branch, isn't it ebough to do a merge from trunk in the second branch? G Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851 VAT Reg No 778499447 From: Graf, Andreas [mailto:andreas.g...@ext.eu.panasonic.com] Sent: 30 June 2010 13:39 To: users@subversion.apache.org Cc: Bruedern, Ivonne Subject: Reintegrate merge to another branch Hi SVN folks! We are using Tortoise reintegrate successfully to merge changes back to the branch that have been used for branch-off. But if we are using reintegrate to apply the same differences to another branch, we are getting bad merge results. Is there a bug-fix for that problem available or is it only possible to do that merge using range-merging? Environment --- Win32-Client svn, version 1.6.11 (r934486) compiled Apr 16 2010, 10:39:09 TortoiseSVN 1.6.8, Build 19260 - 32 Bit , 2010/04/16 20:20:11 Subversion 1.6.11, apr 1.3.8 apr-utils 1.3.9 neon 0.29.3 OpenSSL 0.9.8k 25 Mar 2009 zlib 1.2.3 Linux Server: svn, version 1.6.6 - Best Regards, Andreas Graf .. Confidentiality Notice The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company. If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it. .
Re: auto-props on import use local temp file name instead of remote destination file name
> > Hi Justin, > > On Fri, Jun 25, 2010 at 09:09:39AM -0500, Justin Johnson wrote: > > > I am attempting to import a file and set svn:eol-style in one command > using > > the --auto-props and --config-option options to svn import. When I do > the > > import I explicitly specify the file name in the import URL. The reason > I > > do this is because I want to import from a randomly generated temp file > name > > but I want the file to be named config.ini in the repository. After some > > testing I have determined that svn uses the temp file name when > evaluating > > if an auto-prop should be applied instead of using the remote file name > > specified on the import URL. The test script below reproduces the > problem. > > > > It seems to me that when a path to a file is specified as the import URL, > > svn should use that file name in evaluating the auto-props, but perhaps > > there is some other reason it works this way. If anyone can clarify or > > confirm that this is a bug I would appreciate it. > > Why don't you just rename the file to config.ini before import? > > Tino. > > That is what I'm doing to work around the problem. This doesn't seem intuitive though and I'm wondering if perhaps the Subversion developers didn't think of this case when implementing this feature. It took a while for me to determine what the problem was and I would like it if no one else had to waste that time. Can any Subversion developer weigh in on this? Thanks. Justin
AW: Reintegrate merge to another branch
Hi Giulio, Thank you for your comments. From my point of view, the bennefit of reintegrate is that users do not have to take care about the used revisions, so we would like to use that functionality for submitting changes to other branches too. For instance when we have to provide patches to a test-branch before patches are merged back to trunk. Best regards, Andreas Graf Von: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Gesendet: Mittwoch, 30. Juni 2010 14:47 An: Graf, Andreas; users@subversion.apache.org Cc: Bruedern, Ivonne Betreff: RE: Reintegrate merge to another branch I don't think is possible to use --reintegrate. You can always to a "old style" merge with a revision range. But there is something I don't understand. I presume you have created both branches from trunk, so after you have reintegrated the first branch, isn't it ebough to do a merge from trunk in the second branch? G Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851 VAT Reg No 778499447 From: Graf, Andreas [mailto:andreas.g...@ext.eu.panasonic.com] Sent: 30 June 2010 13:39 To: users@subversion.apache.org Cc: Bruedern, Ivonne Subject: Reintegrate merge to another branch Hi SVN folks! We are using Tortoise reintegrate successfully to merge changes back to the branch that have been used for branch-off. But if we are using reintegrate to apply the same differences to another branch, we are getting bad merge results. Is there a bug-fix for that problem available or is it only possible to do that merge using range-merging? Environment --- Win32-Client svn, version 1.6.11 (r934486) compiled Apr 16 2010, 10:39:09 TortoiseSVN 1.6.8, Build 19260 - 32 Bit , 2010/04/16 20:20:11 Subversion 1.6.11, apr 1.3.8 apr-utils 1.3.9 neon 0.29.3 OpenSSL 0.9.8k 25 Mar 2009 zlib 1.2.3 Linux Server: svn, version 1.6.6 - Best Regards, Andreas Graf .. Confidentiality Notice The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company. If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it. . .. Confidentiality Notice The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company. If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it. .
out of date branches
Hi all, I would like to know if there are any recommendations as to enforce a team to always branch from the latest revision of a branch. There's a big risk that a developer might have forgotten to update a branch, then does a replace (in TortoiseSVN) which overwrites a more recent version of a file. How can this be prevented? Via hook-scripts, settings in TortoiseSVN. I prefer doing SVN copy via right-click drag-n-drop in TortoiseSVN than doing a cryptic Merge. I want to set a good process to ensure that a team never overwrites new stuff Thanks Jan
RE: out of date branches
Subversion doesn’t allow you to commit changes to out of date files and with Subversion 1.6 you would get a tree conflict on updating the replaced file. This tree conflict would explain that there were changes to the file that you replaced. Bert From: Jan Lund [mailto:janne_l...@yahoo.com] Sent: woensdag 30 juni 2010 17:28 To: users@subversion.apache.org Subject: out of date branches Hi all, I would like to know if there are any recommendations as to enforce a team to always branch from the latest revision of a branch. There's a big risk that a developer might have forgotten to update a branch, then does a replace (in TortoiseSVN) which overwrites a more recent version of a file. How can this be prevented? Via hook-scripts, settings in TortoiseSVN. I prefer doing SVN copy via right-click drag-n-drop in TortoiseSVN than doing a cryptic Merge. I want to set a good process to ensure that a team never overwrites new stuff Thanks Jan
RE: Reintegrate merge to another branch
>>> From: Graf, Andreas [mailto:andreas.g...@ext.eu.panasonic.com] >>> We are using Tortoise reintegrate successfully to merge changes >>> back to the branch that have been used for branch-off. >>> >>> But if we are using reintegrate to apply the same differences to >>> another branch, we are getting bad merge results. >>> Is there a bug-fix for that problem available or is it only >>> possible to do that merge using range-merging? >>> >> Von: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] >> I don't think is possible to use --reintegrate. You can always to a >> "old style" merge with a revision range. >> >> But there is something I don't understand. I presume you have >> created both branches from trunk, so after you have reintegrated >> the first branch, isn't it ebough to do a merge from trunk in the >> second branch? > From: Graf, Andreas [mailto:andreas.g...@ext.eu.panasonic.com] > From my point of view, the bennefit of reintegrate is that users do > not have to take care about the used revisions, so we would like to > use that functionality for submitting changes to other branches > too. For instance when we have to provide patches to a test-branch > before patches are merged back to trunk. --reintegrate is used to merge changes made to a branch (copy really) back to its parent/ancestor path. So, your point of view is a bit skewed. Since your branch is not a child copy of the other branch you can not use --reintegrate. You have several options... you can merge from one branch to the other. It just wouldn't be an integration merge... it would be a regular merge. Merge tracking will ensure that you don't merge the same changes more than once. Say you have /trunk /branch/Feature1 /branch/Feature1.1 In the above you copied /trunk to /branch/Feature one. You then branched /branch/Fature1 to /branch/Feature1.1. Let's assume you have made changes to feature 1 and finished those changes. You can --reintegrate Feature1 into trunk. That is fine, since that was its ancestral parent. However, if you want to bring everything you did in Feature1 to Feature1.1 you would merge from /Feature1 into /Feature1.1 but it would NOT be a reintegration merge. Bottom line... reintegrate is always used to put the changes made on a branch back into its parent assuming you have merged all changes made on the parent into that branch first. BOb
RE: out of date branches
> -Original Message- > From: Jan Lund [mailto:janne_l...@yahoo.com] > Sent: Wednesday, June 30, 2010 11:28 AM > To: users@subversion.apache.org > Subject: out of date branches > > Hi all, > > I would like to know if there are any recommendations as to enforce > a team to always branch from the latest revision of a branch. > There's a big risk that a developer might have forgotten to update > a branch, then does a replace (in TortoiseSVN) which overwrites a > more recent version of a file. > > How can this be prevented? Via hook-scripts, settings in > TortoiseSVN. I prefer doing SVN copy via right-click drag-n-drop in > TortoiseSVN than doing a cryptic Merge. I want to set a good > process to ensure that a team never overwrites new stuff > you could probably write a hook script for. But, if you instruct your devs to only do branching from the repository browser it will be done from head... unless they change repo browser to show an earlier revision... but that has to be done on purpose. Bob
AW: Reintegrate merge to another branch
Thank you Bob! -Ursprüngliche Nachricht- Von: Bob Archer [mailto:bob.arc...@amsi.com] Gesendet: Mittwoch, 30. Juni 2010 17:53 An: Graf, Andreas; Giulio Troccoli; users@subversion.apache.org Cc: Bruedern, Ivonne Betreff: RE: Reintegrate merge to another branch >>> From: Graf, Andreas [mailto:andreas.g...@ext.eu.panasonic.com] >>> We are using Tortoise reintegrate successfully to merge changes >>> back to the branch that have been used for branch-off. >>> >>> But if we are using reintegrate to apply the same differences to >>> another branch, we are getting bad merge results. >>> Is there a bug-fix for that problem available or is it only >>> possible to do that merge using range-merging? >>> >> Von: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] >> I don't think is possible to use --reintegrate. You can always to a >> "old style" merge with a revision range. >> >> But there is something I don't understand. I presume you have >> created both branches from trunk, so after you have reintegrated >> the first branch, isn't it ebough to do a merge from trunk in the >> second branch? > From: Graf, Andreas [mailto:andreas.g...@ext.eu.panasonic.com] > From my point of view, the bennefit of reintegrate is that users do > not have to take care about the used revisions, so we would like to > use that functionality for submitting changes to other branches > too. For instance when we have to provide patches to a test-branch > before patches are merged back to trunk. --reintegrate is used to merge changes made to a branch (copy really) back to its parent/ancestor path. So, your point of view is a bit skewed. Since your branch is not a child copy of the other branch you can not use --reintegrate. You have several options... you can merge from one branch to the other. It just wouldn't be an integration merge... it would be a regular merge. Merge tracking will ensure that you don't merge the same changes more than once. Say you have /trunk /branch/Feature1 /branch/Feature1.1 In the above you copied /trunk to /branch/Feature one. You then branched /branch/Fature1 to /branch/Feature1.1. Let's assume you have made changes to feature 1 and finished those changes. You can --reintegrate Feature1 into trunk. That is fine, since that was its ancestral parent. However, if you want to bring everything you did in Feature1 to Feature1.1 you would merge from /Feature1 into /Feature1.1 but it would NOT be a reintegration merge. Bottom line... reintegrate is always used to put the changes made on a branch back into its parent assuming you have merged all changes made on the parent into that branch first. BOb .. Confidentiality Notice The information contained in this Email, and any attachments, is intended for the named recipients only. It may contain confidential and/or legally privileged information. If you are not the intended recipient, you must not copy, store, distribute or take any action in reliance on it. Any views expressed do not necessarily reflect the views of the company. If you receive this Email by mistake, please advise the sender by using the reply facility in your Email software and then delete it. .
RE: out of date branches
Hi! Thanks for reply. Well it was possible. And I'm pretty sure server was 1.6 at the time. All users are using TortoiseSVN. The revision 1174 was copied from 1112 but 1151 had replaced 1146(!!) so 1174 lost everything after 1112! Since user2 hadn't updated to revision 1173 in the "from"-branch... See extract below (I have changed it to be anonymous)! How to avoid this to happen? Regards Jan Revision: 1174 Author: user2 Date: 17:13:34, den 30 juni 2010 Message: Copied from production Added : /projects/new/filename.c (Copy from path: /production/filename.c, Revision, 1112) (.) Revision: 1151 Author: user1 Date: 07:38:28, den 30 juni 2010 Message: >From /releases/old/ Replacing : /production/filename.c (Copy from path: /releases/old/filename.c, Revision, 1146) --- Den ons 2010-06-30 skrev Bert Huijben : Från: Bert Huijben Ämne: RE: out of date branches Till: "'Jan Lund'" , users@subversion.apache.org Datum: onsdag 30 juni 2010 17:46 Subversion doesn’t allow you to commit changes to out of date files and with Subversion 1.6 you would get a tree conflict on updating the replaced file. This tree conflict would explain that there were changes to the file that you replaced. Bert From: Jan Lund [mailto:janne_l...@yahoo.com] Sent: woensdag 30 juni 2010 17:28 To: users@subversion.apache.org Subject: out of date branches Hi all, I would like to know if there are any recommendations as to enforce a team to always branch from the latest revision of a branch. There's a big risk that a developer might have forgotten to update a branch, then does a replace (in TortoiseSVN) which overwrites a more recent version of a file. How can this be prevented? Via hook-scripts, settings in TortoiseSVN. I prefer doing SVN copy via right-click drag-n-drop in TortoiseSVN than doing a cryptic Merge. I want to set a good process to ensure that a team never overwrites new stuff Thanks Jan
RE: out of date branches
Yeah, thanks! Your answer is along the lines of what I've been thinking. Using the repo browser or hook-script. Best would probably be to introduce a hook script which forbids people to branch from an older version than was previously branched. An example of such a script would be GREATLY appreciated! Changes can otherwise get lost in production... --- Den ons 2010-06-30 skrev Bob Archer : Från: Bob Archer Ämne: RE: out of date branches Till: "Jan Lund" , "users@subversion.apache.org" Datum: onsdag 30 juni 2010 17:55 > -Original Message- > From: Jan Lund [mailto:janne_l...@yahoo.com] > Sent: Wednesday, June 30, 2010 11:28 AM > To: users@subversion.apache.org > Subject: out of date branches > > Hi all, > > I would like to know if there are any recommendations as to enforce > a team to always branch from the latest revision of a branch. > There's a big risk that a developer might have forgotten to update > a branch, then does a replace (in TortoiseSVN) which overwrites a > more recent version of a file. > > How can this be prevented? Via hook-scripts, settings in > TortoiseSVN. I prefer doing SVN copy via right-click drag-n-drop in > TortoiseSVN than doing a cryptic Merge. I want to set a good > process to ensure that a team never overwrites new stuff > you could probably write a hook script for. But, if you instruct your devs to only do branching from the repository browser it will be done from head... unless they change repo browser to show an earlier revision... but that has to be done on purpose. Bob
new feature request: maxfilesize
Hello, I am a long term subversion user and use it in my everyday work. Sometimes happens to me that I checkout a local copy of some directory in the repository from a low speed modem connection, if the directory contains a huge file the download time can be extremely high. Because I am not particularly interested in this huge file for me is a waste of both time and disk space in my local copy laptop. Generalizing the problem I think the required feature can be depicted as follows: the new feature (-maxfilesize=) is the maximum size a file must have in order to being brought from the server throught the wire. If a file is greater than such size then a file of several bytes in size is transmitted instead. This bridge file has the same name as the real controlled file, with some lightweight content that is recognizable by subversion. svn co -maxfilesize=200K $REP/trunk/dir src maxfilesize must remain sticky in the directories applied. svn up -maxfilesize=400K or svn up -maxfilesize=none would update the sticky value and replace bridges with full-content files. This way one could checkout trunk from a heavy repository, and start editing very quickly. thank you regards -- Marcos Mayorga FairLuck CO
svn 1.3 crashing after sometime
Hi Gurus, Kindly help me with my problem. Subversion is running fine for sometime and then system load suddenly goes high and no one can login to the server. 172.23.14.1 - - [01/Jul/2010:10:18:36 +0800] "PROPFIND /xyz/branches/prod HTTP/1.1" 401 1263 172.23.14.1 - - [01/Jul/2010:10:18:36 +0800] "PROPFIND /xyz/branches/prod HTTP/1.1" 401 1263 172.23.14.1 - - [01/Jul/2010:10:18:36 +0800] "PROPFIND /xyz/branches/prod HTTP/1.1" 401 1263 172.23.14.1 - - [01/Jul/2010:10:18:37 +0800] "PROPFIND /xyz/branches/prod HTTP/1.1" 401 1263 172.23.14.1 - - [01/Jul/2010:10:18:37 +0800] "PROPFIND /xyz/branches/prod HTTP/1.1" 401 1263 172.23.14.1 - - [01/Jul/2010:10:18:37 +0800] "PROPFIND /xyz/branches/prod HTTP/1.1" 401 1263 Here my spec: svn 1.3 apache 2.2 sles10 sp3 authenticates with windows ad - clients are mostly tortoise (1.5 to 1.6) but there use are very basic: checkin, checkout, copy, mv, update - 90 repositories hosted - one hudson client running every 30 mins which connects to 50+ repositories every repository are defined this way in apache: DAV svn SVNPath /srv/svn/abc AuthName "Please use your ACTIVE DIRECTORY for Authentication" AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative off Include /etc/apache2/.ldapbinddn AuthLDAPURL "ldaps://192.168.1.1 192.168.1.2:636/OU=ADBC,DC=def,DC=local?sAMAccountName?sub?(objectClass=user)" SSLRequireSSL AuthzSVNAccessFile /etc/apache2/svn_acl/abc Require valid-user SVNPathAuthz off mod_ldap setting: LDAPTrustedMode SSL LDAPVerifyServerCert off LDAPSharedCacheSize 50 LDAPCacheEntries 1024 LDAPCacheTTL 43200 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 43200 LDAPConnectionTimeout 3 sysctl.conf: net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.ip_forward = 1 net.ipv4.tcp_syncookies = 1 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_sack = 1 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1 net.core.netdev_max_backlog = 2500 I saw this in my logs: [Wed Jun 30 18:14:13 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 18:14:23 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 18:56:17 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 18:56:22 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:01:07 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:01:10 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:06:43 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:06:48 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:12:15 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:12:25 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:12:37 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:13:12 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:15:38 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:18:24 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:18:44 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] [Wed Jun 30 19:20:27 2010] [error] [client 172.23.139.251] The requested report is unknown. [501, #27] Thanks, West
Re: Error:1053 when starting Subverion as a Windows 2008 Server R2 service
On Wed, Jun 30, 2010 at 4:41 PM, Roberto de Castro wrote:
> Hi Csaba Raduly!
> This is Event Viewer log message:
> Log Name: System
> Source: Service Control Manager
> Date: 30/06/2010 11:32:57
> Event ID: 7000
> Task Category: None
> Level: Error
> Keywords: Classic
> User: N/A
> Computer: ingressoserver
> Description:
> The Subversion Ingresso.com service failed to start due to the following
> error:
> The service did not respond to the start or control request in a timely
> fashion.
> Event Xml:
> http://schemas.microsoft.com/win/2004/08/events/event";>
>
> Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service
> Control Manager" />
> 7000
> 0
> 2
> 0
> 0
> 0x8080
>
> 10498
>
>
> System
> ingressoserver
>
>
>
> Subversion Ingresso.com
> %%1053
>
>
That wasn't much help, unfortunately.
Have you tried running svnserve directly, with the same options but
without the -service, from the command line?
--
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds
