could not execute PROPPATCH on master repository
I’m trying to use the apache write through proxy for the svn repository. After svnsync init and sync I checkout the repository (via the slave) and try to commit something (with tortoiseSVN 1.6.10) to it but get the error message “”” Commit failed (details follow): At least one property change failed; repository is unchanged Error setting property ‘log’: Could not execute PROPPATCH. “”” Any ideas on what could cause this? Windows server 2008 on both master and slave I’m using https in port 4430 in both the slave and master apache. Master apache logs/error.log: [Thu Oct 28 16:26:22 2010] [notice] Apache/2.2.17 (Win32) SVN/1.6.13 mod_auth_sspi/1.0.4 DAV/2 mod_ssl/2.2.17 OpenSSL/0.9.8o configured -- resuming normal operations [Thu Oct 28 16:26:22 2010] [notice] Server built: Oct 18 2010 01:58:12 [Thu Oct 28 16:26:22 2010] [notice] Parent: Created child process 41108 [Thu Oct 28 16:26:22 2010] [notice] Child 41108: Child process is running [Thu Oct 28 16:26:22 2010] [notice] Child 41108: Acquired the start mutex. [Thu Oct 28 16:26:22 2010] [notice] Child 41108: Starting 64 worker threads. [Thu Oct 28 16:26:22 2010] [notice] Child 41108: Starting thread to listen on port 4430. [Thu Oct 28 16:26:22 2010] [notice] Child 41108: Starting thread to listen on port 8090. … [Thu Oct 28 16:29:31 2010] [error] [client …] (OS 87)The parameter is incorrect. : authentication failure for "/svn-apache/newrepo/!svn/act/abd4aa2d-d327-4f49-9d5f-934da03106ae": user unknown, reason: cannot generate context [Thu Oct 28 16:29:42 2010] [error] [client…] Could not execute PROPPATCH. [500, #206] [Thu Oct 28 16:29:42 2010] [error] [client …] Properties may only be defined in the http://subversion.tigris.org/xmlns/svn/ and http://subversion.tigris.org/xmlns/custom/ namespaces. [409, #0] Slave apache logs/error.log does not show anything about the attempt. The startup generates this information: [Thu Oct 28 16:26:18 2010] [notice] Apache/2.2.17 (Win32) DAV/2 mod_auth_sspi/1.0.4 SVN/1.6.13 mod_ssl/2.2.17 OpenSSL/0.9.8o configured -- resuming normal operations [Thu Oct 28 16:26:18 2010] [notice] Server built: Oct 18 2010 01:58:12 [Thu Oct 28 16:26:18 2010] [notice] Parent: Created child process 86268 [Thu Oct 28 16:26:19 2010] [notice] Child 86268: Child process is running [Thu Oct 28 16:26:19 2010] [notice] Child 86268: Acquired the start mutex. [Thu Oct 28 16:26:19 2010] [notice] Child 86268: Starting 64 worker threads. [Thu Oct 28 16:26:19 2010] [notice] Child 86268: Starting thread to listen on port 4430. [Thu Oct 28 16:26:19 2010] [notice] Child 86268: Starting thread to listen on port 8090. Any help would be appreciated Sakari
Advice on process for web development
Hi, I'm working with our Web Team to re-engineer their development process. All the code is already under Subversion, but everything is in one big directory. They're not using any branch or tags for that matter. And of course, testing is not as rigorous and controlled as it should be. Anyway, I have suggested the usual trunk/branches/tags layout. Developers will normally work on branches, but can occasionally work directly on trunk for easy and quick fixes. The tester will create a QA branch as a copy of trunk at a specific revision. When they are happy that a QA is ready for releasing, a tag is created from the QA (or maybe from trunk again at the same revision). I think they will go for such a solution, even though it means that they cannot pick-and-choose what to test. If they want to test a bug fixed in revision 1000, they will also test all bugs fixed in previous revision. The problem is that they may want to fast track an urgent bug fix. It shouldn't happen often, but it may happen so I need to come up with a solution for that case too. What I'm thinking is something like the following. Let's supposed that 1.1 is the latest release, i.e. it's what's in production. i) the developer creates a branch off the tag svn cp http:///tags/1.1 http:///branches/1.1_urgent_fix -m"Creating branch fro urgent bug 123456" ii) the developer makes all the necesary, coding and testing iii) the fix is merged back to trunk cd trunk svn merge ^/branches/1.1_urgent_fix . svn ci -m"Fixing urgent bug 123456" iv) the branch goes live svn cp http:///branches/1.1_urgent_fix http:///tags/1.2 -m"Fixed bug 123456" switch the production site to point to ^/tags/1.2 v) at this point all the QA are useless because the do not contain the urgent fix, so a new QA must be created svn cp -rHEAD http:///trunk http:///tags/QA_1.3_1 -m"Created first QA for 1.3" Now my questions. 1 - Do you have any comments on the process and/or any suggestions? 2 - Would the merge, in step iii, do the right thing and merge all revisions committed into the branch into trunk? I can't use --reintegrate becuase I haven't previously merged from trunk to the branch (as the branch was created as a copy of a tag). 3 - I don't really like the fact that after the fix has gone live, we are forced to create a QA from HEAD, which means testing everything that has gone into trunk, but I can't think of another way to make sure the fix is indeed included in the Qas and especially in the next (1.3 in this case) release. Thank you in advance. Giulio Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Re: verification of user id '' not configured
Enrique Porta wrote on Fri, Oct 29, 2010 at 08:17:54 +0200: > Hi! i have an apache 2.2.15 server and i want to configure a secure folder. > > This is my secure configuration > > Try dropping the trailing slash. > DAV svn > SVNParentPath /var/lib/svn > SVNListParentPath On > > AuthType Digest Add an AuthDigestProvider directive? > AuthName "Private" > AuthUserFile /etc/svn-auth-file > AuthzSVNAccessFile /etc/svn-authz-file > Require valid-user > > > The svn-auth-file are create wit the htdigest command and the "Private" realm > . > > The content of the svn-authz-file is: [/] * = r > > The webrowser show me the login window, but on the server error log > appears this: > > verification of user id '' not configured > > I try using the AuthType Basic with a htpasswd file and all works > perfectly, but with the Digest no > > What's the problem? > > Thx ;)
Secure Connection Truncated/Insufficient system resources
Hi, I'm getting a lot of errors when performing svn checkouts or updates. On the client side they appear as follows: Error: REPORT of '/svn//!svn/vcc/default': Could not read chunk size: Error: Secure connection truncated In the Apache SSL error log on the server the corresponding message is: [Fri Oct 29 13:10:15 2010] [error] [client ] Provider encountered an error while streaming a REPORT response. [500, #0] [Fri Oct 29 13:10:15 2010] [error] [client ] A failure occurred while driving the update report editor [500, #721450] [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read file 'E:\\repositorydb\\revs\\20\\20795': Insufficient system resources exist to complete the requested service. After searching the mailing list archives and google for similar issues I tried the following changes: 1) Added an exclusion on the client side for my workspace folder to the Antivirus software 2) Set "SVNPathAuthz Off" in the server config 3) Set "Timeout" to 5 in the server config 4) Set "KeepAliveTimeout" to 25 in the server config Unfortunately none of them have worked. The "Insufficient system resources" message suggests a problem with the server but I don't see anything hogging memory or CPU and available disk space is fine. The repository is quite large if that makes a difference (278 Gb on the server). Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003 Client: TortoiseSVN 1.6.11 on Windows 7 Any ideas on what else I can try or advice on how I can further debug the problem? Also, what do those numbers at the end of the error lines, e.g. "[500, #721450]" mean? Regards, Martin Bagnall
Moving to Subversion for PL-SQL development
First of all let me tell you that I don't know much of how PL-SQL development works so I might say something really obvious to you or more likely just wrong. Please forgive me. I have a team that uses StarTeam as their VCS and we are now working on moving the project to Subversion. We are planning to use an importer for the initial load of the repository which seems to do what they want (I'm not looking after that part). I have a problem though with their releasing process. As I understand it, a major release is formed by all the packages and scripts, plus some table initialisation and sometime some data (I presume for defaults and stuff like that). Minor releases are done with patches which included only the packages that have changed from the previous patch. So, if I want 5.4.0 (major release), I get everything. I unpack the kit, install it, run it, whatever it take and I'm done. If I am already on 5.4.0 and I want 5.4.3 (a minor release) I will be sent 3 patches: to 5.4.1, then 5.4.2 and finally 5.4.3. Apparently I just need to unzip them and I'm done. Now, I might not be clear in the above process, so if someone with more experience with PL-SQL development and release wants to correct me, please do. I know there isn't one way to do things, but it's more likely that I understood wrong than we are doing it in a special way. Anyway, if I am right, I'm struggling to come up with a process using Subversion. It seems they do not want to tag everything in trunk because that would be like a major release (apparently it would include those table and data things). Maybe we could re-organised the code to separate the packages from the data and then we could tag the packages, which is more what they want. And this way, to go to 5.4.3 I won't need 5.4.1 and 5.4.2 at all, which in my opinion is even better. In the end what I am looking for with this email is some advice on how to proceed from people with more experience than me in projects using PL-SQL. Thanks Giulio Troccoli Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Re: Secure Connection Truncated/Insufficient system resources
On Fri, Oct 29, 2010 at 2:35 PM, Bagnall, Martin wrote: > In the Apache SSL error log on the server the corresponding message is: > > [Fri Oct 29 13:10:15 2010] [error] [client ] Provider > encountered an error while streaming a REPORT response. [500, #0] > > [Fri Oct 29 13:10:15 2010] [error] [client ] A failure occurred > while driving the update report editor [500, #721450] > > [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read file > 'E:\\repositorydb\\revs\\20\\20795': Insufficient system > resources exist to complete the requested service. > > > The “Insufficient system resources” message suggests a problem with the > server but I don’t see anything hogging memory or CPU and available disk > space is fine. The repository is quite large if that makes a difference (278 > Gb on the server). Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large binary files in there? Maybe the "insufficient resource" is related to the number of open file handles? I don't know how this works on Windows (or how you can configure it), but on *nix you have things like "ulimit" to limit the maximum number of file descriptors a process can have open simultaneously. Is there anything special about revision 20795, the one that is referenced in the "insufficient system resources" message? Is it a very large rev file in the repository (the file 'E:\\repositorydb\\revs\\20\\20795')? Cheers, Johan > > Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003 > > Client: TortoiseSVN 1.6.11 on Windows 7
RE: Advice on process for web development
CC-ing the list > -Original Message- > From: Luiz Guilherme Kimel [mailto:lki...@dba.com.br] > Sent: 29 October 2010 15:44 > To: Giulio Troccoli > Subject: RES: Advice on process for web development > > Giulio, > > I would recommend you a reference book for SCM patterns. Try > ADDISON WESLEY Software Configuration Management Patterns. It > has solutions > > Answering your questions, you need to stablish baselines for > your software. > Branches will have one baseline as their common start point, > as their "base". This base will usually be a stable version > of your software. Let's say your baseline is exactly your > current production release. What you're saying is that the branches should be created as copies of trunk at a specific revision, i.e. the production one. Have I understood correctly? > Sometimes your baseline will evolve. Maybe because your QA > team approved some new features for production, maybe because > you made urgent corrections. > If it's approved for production it will be your new baseline. > All branches from this baseline will need to be "rebased" > before releasing, they need to incorporate any production changes. So, basically, I need to merge changes in trunk from the previous "production" revision to the current "production" revision (which may not be HEAD at all) to the branches. > Your correction will be tested isolated, approved and merged > to your trunk for tagging and release. If your development > branches are based on the trunk, then you will need to merge > trunk changes to each development branch to rebase them. Use > the development branch for integration so that the next > approved branch will always merge to the trunk with no > possibility of conflict. After rebasing, apply new QA tests. I'm not sure I understand you here. After the development in a branch has been completed, the branch is tested and if approved merged back into the trunk. Surely though I need to test trunk as well. I didn't say, but yes when a branch is reintegrated into the trunk, the other branches should merge from trunk to get those changes. > Why your QA team have a branch??? They won't ever make > changes, so all they need is a tag. I mean, in SVN it's the > samething, but in the concept it's a lot different. The QA team does not have a branch. I realised I said "create a QA branch as a copy of trunk" but then in the command I did create the "branch" in tags. Which doesn't mean that they cannot change it, but it will be prevented and, as you said, conceptually is different. > Do you already use any project management and bug tracking > tool? If not, I would recommend MantisBT. We do. It's actually part of what the Web Team does. Thanks for your input, however, you haven't touched on the main issues I have, which is about the case of an urgent fix. Giulio > Best Regards, > Luiz Guilherme M. Kimel > > > -Mensagem original- > De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > Enviada em: sexta-feira, 29 de outubro de 2010 09:20 > Para: users@subversion.apache.org > Assunto: Advice on process for web development > > Hi, > > I'm working with our Web Team to re-engineer their > development process. All the code is already under > Subversion, but everything is in one big directory. They're > not using any branch or tags for that matter. And of course, > testing is not as rigorous and controlled as it should be. > Anyway, I have suggested the usual trunk/branches/tags layout. > > Developers will normally work on branches, but can > occasionally work directly on trunk for easy and quick fixes. > The tester will create a QA branch as a copy of trunk at a > specific revision. When they are happy that a QA is ready for > releasing, a tag is created from the QA (or maybe from trunk > again at the same revision). > > I think they will go for such a solution, even though it > means that they cannot pick-and-choose what to test. If they > want to test a bug fixed in revision 1000, they will also > test all bugs fixed in previous revision. > > The problem is that they may want to fast track an urgent bug > fix. It shouldn't happen often, but it may happen so I need > to come up with a solution for that case too. > > What I'm thinking is something like the following. Let's > supposed that 1.1 is the latest release, i.e. it's what's in > production. > i) the developer creates a branch off the tag > svn cp http:///tags/1.1 http:// REPO>/branches/1.1_urgent_fix -m"Creating branch fro urgent > bug 123456" > ii) the developer makes all the necesary, coding and testing > iii) the fix is merged back to trunk > cd trunk > svn merge ^/branches/1.1_urgent_fix . > svn ci -m"Fixing urgent bug 123456" > iv) the branch goes live > svn cp http:///branches/1.1_urgent_fix > http:// REPO>/tags/1.2 -m"Fixed bug 123456" > switch the production site to point to ^/tags/1.2 > v) at th
RES: Moving to Subversion for PL-SQL development
Hi Giulio, I'm curious about how you manage your PL/SQL development and identify packages and its versions and how do you manage concurrency. Until were I know Oracle won't manage concurrency when two developers edit the same package and once broke, the entire package stop working. I used, in a past project, to ask the team to save packages as text files in the repository and lock them to signalize someone is working on it. The live package being edited should be edited with a different name like "package_name_plus_developers_user_name" so that the package won't be broken for other developers. Once the developer finished to edit the package and make his own tests he would increase its version number (a simple comment in the package interface and body), write a small changelog as a comment, submit it to the repository, release de lock, update package with its real name and delete the temporary one. Sounds a little troublesome, but I couldn't think of a better process. Later I included a version function inside each package so I could check packages versions using an sql script. "It seems they do not want to tag everything in trunk because that would be like a major release (apparently it would include those table and data things). Maybe we could re-organised the code to separate the packages from the data and then we could tag the packages, which is more what they want." Yes, you can have a BTT (branch, tags, trunk) structure for the database DDL including packages, another BTT for documentation and another for source code and manage their evolution separately if it fits better to your team. Instead of one big configuration item now you have 3 to care about. The database definition versions can have patches to update a live database from version a to version b. But anyway you will need to build your high level configuration item, which will represent your entire software package including database, code, documentation etc in its specific compatible version. This set, you can release software. Your installer can check each configuration item version to decide what to do (database version updates, documentation version). There are things that can be just deleted and overwritten (like binaries and help), but database will usually need to be patched. Having the database and plsql code as an independent configuration item sounds good to me. I'm not sure I'm helping... lol Luiz Guilherme M. Kimel -Mensagem original- De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Enviada em: sexta-feira, 29 de outubro de 2010 10:11 Para: users@subversion.apache.org Assunto: Moving to Subversion for PL-SQL development First of all let me tell you that I don't know much of how PL-SQL development works so I might say something really obvious to you or more likely just wrong. Please forgive me. I have a team that uses StarTeam as their VCS and we are now working on moving the project to Subversion. We are planning to use an importer for the initial load of the repository which seems to do what they want (I'm not looking after that part). I have a problem though with their releasing process. As I understand it, a major release is formed by all the packages and scripts, plus some table initialisation and sometime some data (I presume for defaults and stuff like that). Minor releases are done with patches which included only the packages that have changed from the previous patch. So, if I want 5.4.0 (major release), I get everything. I unpack the kit, install it, run it, whatever it take and I'm done. If I am already on 5.4.0 and I want 5.4.3 (a minor release) I will be sent 3 patches: to 5.4.1, then 5.4.2 and finally 5.4.3. Apparently I just need to unzip them and I'm done. Now, I might not be clear in the above process, so if someone with more experience with PL-SQL development and release wants to correct me, please do. I know there isn't one way to do things, but it's more likely that I understood wrong than we are doing it in a special way. Anyway, if I am right, I'm struggling to come up with a process using Subversion. It seems they do not want to tag everything in trunk because that would be like a major release (apparently it would include those table and data things). Maybe we could re-organised the code to separate the packages from the data and then we could tag the packages, which is more what they want. And this way, to go to 5.4.3 I won't need 5.4.1 and 5.4.2 at all, which in my opinion is even better. In the end what I am looking for with this email is some advice on how to proceed from people with more experience than me in projects using PL-SQL. Thanks Giulio Troccoli Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Revisions not in chronological order
Hi, My repository is made up of a load of folder loaded from cvs2svn dumps. These were loaded individually and have overlapping date ranges. When doing an "svn load" it looks like SVN assigns each commit to the next revision, regardless of the date the commit occurred. As a result the rage of revisions created for each of the loads have overlapping dates and the revisions of the repository are not chronological. E.g. C:\Windows\system32>svn log -v -r 2000 https://svn/svn/repo/ r2000 | | 2006-07-13 11:41:27 +0100 (Thu, 13 Jul 2006) | 2 lines Changed paths: M /Folder1/file1 Message1 C:\Windows\system32>svn log -v -r 2 https://svn/svn/repo/ r2 | | 2003-08-19 04:30:07 +0100 (Tue, 19 Aug 2003) | 1 line Changed paths: A /Folder2/file1 Message2 C:\Windows\system32>svn log -v -r 21000 https://svn/svn/repo/ r21000 | | 2006-05-19 11:55:33 +0100 (Fri, 19 May 2006) | 1 line Changed paths: A /Folder2/file2 Message2 This causes problems for "svn log" and "svn cat" when attempting to get revisions at a particular date for a folder. SVN will find the lowest numbered revision for that date, regardless of whether the folder exists for that revision. e.g. C:\Windows\system32>svn log -r {2010-07-11} https://svn/svn/repo/Folder3 svn: Unable to find repository location for 'https://svn/svn/repo/Folder3' in revision 63506 However there are revisions for that date... C:\Windows\system32>svn log -r 114691 https://svn/svn/repo/Folder3 r114691 | | 2010-07-11 11:12:14 +0100 (Sun, 11 Jul 2010) | 2 lines message 4 I've tried "svndumptool check" to check a dump of the entire repository, but it comes back ok. An "svn load" of the dump seems to keep the same revision numbers and dates. Is there a way of reorganising the repository to have all revisions in chronological order? How can I avoid this happening in the future? Or is there some other way for getting round this? Thanks Chris -- Gloucester Research Limited believes the information provided herein is reliable. While every care has been taken to ensure accuracy, the information is furnished to the recipients with no warranty as to the completeness and accuracy of its contents and on condition that any errors or omissions shall not be made the basis for any claim, demand or cause for action. The information in this email is intended only for the named recipient. If you are not the intended recipient please notify us immediately and do not copy, distribute or take action based on this e-mail. All messages sent to and from this email address will be logged by Gloucester Research Ltd and are subject to archival storage, monitoring, review and disclosure. Gloucester Research Limited, 5th Floor, Whittington House, 19-30 Alfred Place, London WC1E 7EA. Gloucester Research Limited is a company registered in England and Wales with company number 04267560. --
RE: Revisions not in chronological order
> Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03 -Original Message- > From: Chris Evans [mailto:chris.ev...@gresearch.co.uk] > Sent: 29 October 2010 15:42 > To: 'users@subversion.apache.org' > Subject: Revisions not in chronological order > > Hi, > > My repository is made up of a load of folder loaded from > cvs2svn dumps. > These were loaded individually and have overlapping date ranges. > When doing an "svn load" it looks like SVN assigns each > commit to the next revision, regardless of the date the > commit occurred. > > As a result the rage of revisions created for each of the > loads have overlapping dates and the revisions of the > repository are not chronological. This is expected behaviour if have loaded two or more dumps into the same repository. I seem to remember there is a tool out there to merge dumps file, but I don't remember the name. I don't even know if it would merge them in chronological order or not. Google it and see what you can find. Giulio
Re: Advice on process for web development
On 10/29/2010 9:04 AM, Giulio Troccoli wrote: Sometimes your baseline will evolve. Maybe because your QA team approved some new features for production, maybe because you made urgent corrections. If it's approved for production it will be your new baseline. All branches from this baseline will need to be "rebased" before releasing, they need to incorporate any production changes. So, basically, I need to merge changes in trunk from the previous "production" revision to the current "production" revision (which may not be HEAD at all) to the branches. Or just make different 'cuts' from the trunk to new QA branches, which, if everything works can be copied unchanged to production tags. If you have to make changes in QA, you have to make an additional decision as to whether the fix needed there also applies to the ongoing trunk, and if so, merge it - or maybe it has already been done on the trunk. Why your QA team have a branch??? They won't ever make changes, so all they need is a tag. I mean, in SVN it's the samething, but in the concept it's a lot different. If things never change between the cut from trunk and the production release, what's the point of the QA step? It is possible, in fact likely, that you'll need changes for a release after the trunk has moved on to include things you don't want in this release. The QA team does not have a branch. I realised I said "create a QA branch as a copy of trunk" but then in the command I did create the "branch" in tags. Which doesn't mean that they cannot change it, but it will be prevented and, as you said, conceptually is different. If you made a tag for QA you can always copy it out to a branch after discovering it needs changes. Thanks for your input, however, you haven't touched on the main issues I have, which is about the case of an urgent fix. If you had a QA branch corresponding to each release, you'd have an obvious place to make maintenance fixes specific to that release. But that doesn't solve your problem of making sure the fix also is done in the trunk - unless you do the work on the trunk and merge to the branch to add the fix. How you do that needs to be a human decision, not driven by the process. If the process could solve all your problems you wouldn't need this urgent fix in the first place, you'd have caught it in QA. Since it is something unexpected, you need to understand it and figure out separately how it relates to the now-different trunk. -- Les Mikesell lesmikes...@gmail.com -- Les Mikesell lesmikes...@gmail.com
mergeinfo not inherrited when I thought it should
Hello, In a quick test, we have a project which has the following structure: /trunk/project/subfolder/file Next, we create a branch from /trunk/project to /branches/project/branch1/ We edit file on trunk a first time, changing line1 and commit Inside branch1, we do a merge from trunk. This creates mergeinfo on /branches/project/branch1 We edit file on trunk a second time, reverting line1, changing line2 and commit Inside branch1/subfolder, we do a merge from trunk/subfolder. This last step ignores the mergeinfo on /branches/project/branch1/ and merges all revisions again since we made the branch. I thought inherrited mergeinfo would be used here to see that a first part of the revision range did not need to be merged again. However, this does not happen. The result is that we merge the combination of the 2 edits, which is only changing line2. However, we had already merged the change to line1, so the revert on line1 should have been merged too. See attachment for a reproduction scenario. Is this scenario supposed to be handled by SVN ? We are in a corporate environment, using 1.5.1. Is the above scenario known to be handled correctly in later versions? Is it a known issue? Do I try something which is not supported by SVN? Kind regards, Pieter-Jan Busschaert mkdir mergetest cd mergetest mkdir trunk cd trunk mkdir subdir cd subdir echo "line1 00" > test.txt echo "" >> test.txt echo "line2 02" >> test.txt echo "" >> test.txt echo "line3 01" >> test.txt cd .. cd .. svn import https:///mergetest cd .. rm -rf mergetest svn co https:///mergetest mergetest cd mergetest svn up svn cp https:///mergetest/trunk https:///mergetest/branch svn up cd trunk/subdir echo "line1 00" > test.txt echo "" >> test.txt echo "line2 02" >> test.txt echo "" >> test.txt echo "line3 02" >> test.txt svn ci cd ../.. cd branch svn merge https:///mergetest/trunk svn ci svn propget svn:mergeinfo . cd .. cd trunk/subdir echo "line1 00" > test.txt echo "" >> test.txt echo "line2 03" >> test.txt echo "" >> test.txt echo "line3 01" >> test.txt svn ci cd ../.. cd branch/subdir svn propget svn:mergeinfo . svn propget svn:mergeinfo .. svn merge https:///mergetest/trunk/subdir svn propget svn:mergeinfo . svn propget svn:mergeinfo .. svn ci cd ../..
RE: mergeinfo not inherrited when I thought it should
> > Hello, > > In a quick test, we have a project which has the following structure: > > /trunk/project/subfolder/file > > Next, we create a branch from /trunk/project to > > /branches/project/branch1/ > > We edit file on trunk a first time, changing line1 and commit > > Inside branch1, we do a merge from trunk. This creates mergeinfo on > /branches/project/branch1 > > We edit file on trunk a second time, reverting line1, > changing line2 and commit > > Inside branch1/subfolder, we do a merge from trunk/subfolder. Do you mean trunk/project/subfolder here? Anyway, branch1/subfolder does not have any mergeinfo, since the previous merge was done on branch1. So Subversion does not know that you have already merged the changes to line 1. Merges from trunk to branch and vice-versa should always be done from the root of the project (in your case branches/project/branch1) > > This last step ignores the mergeinfo on > /branches/project/branch1/ and merges all revisions again > since we made the branch. I thought inherrited mergeinfo > would be used here to see that a first part of the revision > range did not need to be merged again. However, this does not happen. > > The result is that we merge the combination of the 2 edits, > which is only changing line2. > However, we had already merged the change to line1, so the revert on > line1 should have been merged too. > > See attachment for a reproduction scenario. > > Is this scenario supposed to be handled by SVN ? > We are in a corporate environment, using 1.5.1. Is the above > scenario known to be handled correctly in later versions? I don't think so, as I think Subversion did the correct thing, given the information it has. However, I recommend you to push for an upgrade of SVN, as I remember 1.5 was not particularly good with merging. > Is it a known issue? > Do I try something which is not supported by SVN? > > > Kind regards, > > Pieter-Jan Busschaert > Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
RE: mergeinfo not inherrited when I thought it should
> In a quick test, we have a project which has the following > structure: > > /trunk/project/subfolder/file > > Next, we create a branch from /trunk/project to > > /branches/project/branch1/ > > We edit file on trunk a first time, changing line1 and commit > > Inside branch1, we do a merge from trunk. This creates mergeinfo on > /branches/project/branch1 > > We edit file on trunk a second time, reverting line1, changing > line2 and commit > > Inside branch1/subfolder, we do a merge from trunk/subfolder. > > > This last step ignores the mergeinfo on /branches/project/branch1/ > and merges all revisions again since we made the branch. I thought > inherrited mergeinfo would be used here to see that a first part of > the revision range did not need to be merged again. However, this > does not happen. Did you commit the first merge? BTW: To minimize the merge info propgation you really just always merge from /trunk/project into your branch. If you only want a specific revision you can specify it... but still you want to keep all the mergeinfo in /branches/project/branch1 if you can... or else merges will start changing all kinds of properties on all your child nodes. > The result is that we merge the combination of the 2 edits, which > is only changing line2. > However, we had already merged the change to line1, so the revert > on > line1 should have been merged too. > > See attachment for a reproduction scenario. > > Is this scenario supposed to be handled by SVN ? > We are in a corporate environment, using 1.5.1. Is the above > scenario known to be handled correctly in later versions? > Is it a known issue? There were many merge issues fixed after 1.5.1.. you should get to the latest 1.6... or at the very least the latest 1.5. BOb
RE: Secure Connection Truncated/Insufficient system resources
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: 29 October 2010 14:43 > To: Bagnall, Martin > Cc: users@subversion.apache.org > Subject: Re: Secure Connection Truncated/Insufficient system resources > > On Fri, Oct 29, 2010 at 2:35 PM, Bagnall, Martin > wrote: > > In the Apache SSL error log on the server the corresponding message > is: > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] Provider > > encountered an error while streaming a REPORT response. [500, #0] > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] A failure > occurred > > while driving the update report editor [500, #721450] > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read > file > > 'E:\\repositorydb\\revs\\20\\20795': Insufficient > system > > resources exist to complete the requested service. > > > > > > > The "Insufficient system resources" message suggests a problem with > the > > server but I don't see anything hogging memory or CPU and available > disk > > space is fine. The repository is quite large if that makes a > difference (278 > > Gb on the server). > > Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large > binary files in there? Yes, there are a lot of binary files in there. None are particularly large by themselves but there are many of them. > > Maybe the "insufficient resource" is related to the number of open > file handles? I don't know how this works on Windows (or how you can > configure it), but on *nix you have things like "ulimit" to limit the > maximum number of file descriptors a process can have open > simultaneously. I'm not sure how they work on Windows either but I'll take a look - thanks. > > Is there anything special about revision 20795, the one that is > referenced in the "insufficient system resources" message? Is it a > very large rev file in the repository (the file > 'E:\\repositorydb\\revs\\20\\20795')? I've checked the revision (and others referenced in similar errors, some from other repositories) and they all seem to involve a lot of files - again, none of the files are particularly large by themselves but there's a great deal of them associated with each commit. > > Cheers, > Johan > > > > > Server: Apache 2.2.15 with Subversion 1.6.11 on Windows Server 2003 > > > > Client: TortoiseSVN 1.6.11 on Windows 7
RE: Revisions not in chronological order
Giulio Troccoli wrote: >> From: Chris Evans [mailto:chris.ev...@gresearch.co.uk] >> My repository is made up of a load of folder loaded from >> cvs2svn dumps. >> These were loaded individually and have overlapping date ranges. >> When doing an "svn load" it looks like SVN assigns each >> commit to the next revision, regardless of the date the >> commit occurred. >> >> As a result the rage of revisions created for each of the >> loads have overlapping dates and the revisions of the >> repository are not chronological. > >This is expected behaviour if have loaded two or more dumps into the same repository. > >I seem to remember there is a tool out there to merge dumps >file, but I don't remember the name. I don't even know if >it would merge them in chronological order or not. Google >it and see what you can find. http://svn.borg.ch/svndumptool/ Haven't tried it myself, but it claims to do what you want. Kind regards, Jon ** This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Cabot Communications Limited Verona House, Filwood Road, Bristol BS16 3RY, UK +44 (0) 1179584232 Co. Registered in England number 02817269 Please contact the sender if you believe you have received this email in error. ** __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
write permission issues with repository hosting
Hi, We're running Subversion 1.6.12 on a Solaris 10 machine and hosting repositories on it. Users can create and use repositories via svnadmin and svn locally on the Solaris machine via file:///, or they can check in and out via TortoiseSVN 1.6.8 on their PC via the http:/// protocol, with LDAP verification. For a while this worked flawlessly, but then the machines were reconfigured and we can't get it to work. We can either create and use the repositories locally but not through Tortoise (we get the permission denied on txn-current-lock error) or we can use Tortoise but then not check in locally (failed due to attempt to write a readonly database). We've read the help on Supporting Multiple Repository Access Methods at http://svnbook.red-bean.com/en/1.5/svn.serverconfig.multimethod.html and have tried those steps, though we're not sure what user should initially own the repository (webservd, daemon?). If anyone could point to us to further online docs or pointers we'd appreciate it! matthew
Re: Secure Connection Truncated/Insufficient system resources
Johan Corveleyn wrote on 10/29/2010 08:43:26 AM: > > In the Apache SSL error log on the server the corresponding message is: > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] Provider > > encountered an error while streaming a REPORT response. [500, #0] > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] A failure occurred > > while driving the update report editor [500, #721450] > > > > [Fri Oct 29 13:10:15 2010] [error] [client ] Can't read file > > 'E:\\repositorydb\\revs\\20\\20795': Insufficient system > > resources exist to complete the requested service. > > > > > > > The ?Insufficient system resources? message suggests a problem with the > > server but I don?t see anything hogging memory or CPU and available disk > > space is fine. The repository is quite large if that makes a difference (278 > > Gb on the server). > > Wow, 278 Gb for a repository is *huge* IMHO. Are there a lot of large > binary files in there? One would wish this to be true. I have many >300GB... > Maybe the "insufficient resource" is related to the number of open > file handles? I don't know how this works on Windows (or how you can > configure it), but on *nix you have things like "ulimit" to limit the > maximum number of file descriptors a process can have open > simultaneously. > > Is there anything special about revision 20795, the one that is > referenced in the "insufficient system resources" message? Is it a > very large rev file in the repository (the file > 'E:\\repositorydb\\revs\\20\\20795')? Is the repository packed? I also was fairly regularly seeing this error after I packed a large number of repositories on a windows server. (Not sure that was related since I did see it less frequently before the packing. SAN vendors were changed and I also bumped up the mod_dav version a few minor revs near same time.) The error is not always on the same repository nor even on the same revision or pack file. In most cases when this error occurs I was unable to login to a new session on the server. It seems that Windows 2003 (and before) has some fixed size memory buffers that can cause this problem. You can take a look at: http://support.microsoft.com/kb/935649 (There are other kb articles that apply as well. Just google for the mentioned registry keys.) Reconfiguring the mentioned registry keys seems to have helped this server. It does require a reboot and the usual disclaimer that making changes with regedit could completely disable your machine applies... Server 2008 supposedly dynamically allocates these paged memory pools, so upgrading may also help. Kevin R.
RES: Advice on process for web development
Let me try explain it better... Let's say I just built the first version of an application, so I don't currently have any branch, just the trunk where a small team of developers were working until now. Our last build was tagged as 1.0.0.54 meaning it's our 54 build of the 1.0 version. The QA team approved this build and it becomes our first release of the software. Tag 1.0.0.54 is our baseline which is equal to our trunk at that moment. Now we have two new modules to develop in parallel. The team will receive more people to speed up next releases, so we decided to start working with branches. Two new branches are created: /branches/1.1a and /branches/1.1b. Trunk is locked. Only reading is allowed. Developers are allowed to write only on branches. Team 1 tags the build 1.1a.12 and Team 2 tags the build 1.1b.5 for testing. QA approves 1.1b.5 as a release candidate with partial planned functionality that our client will test. Development continues on both branches. 5 bugs in production are identified. We find that 2 of them are critical and 3 are not and will take some time to fix. We plan for two correction releases, one for 2 days and another for 5 days. So we start only one new branche called 1.0.1 both copied from tag 1.0.0.54. Build 1.0.1.5 delivers planned fixes for version 1.0.1 and is approved for releasing by the QA team. This tag is then merged into trunk with no conflicts since there are no other changes committed to the trunk. Version 1.0.1.5 becomes our new baseline, which is reflected in trunk. Branches 1.1a and 1.1b are now outdated and need to be rebased to include changes to the baseline. Team 2 (1.1b) stops development and merge trunk changes to its branch. Team 1 decides not to rebase now and development continues. Client approved release candidate 1.1b.5 and wants it to go for production with the partial functionality built. Team 2 already made changes to 1.1.b branch. So they open a new branch 1.1.1.0 from tag 1.1.b.5 and merge the trunk to it. Team 2 notifies QA that changes are not conflicting. QA makes regretion tests and finds no problem. Branch 1.1.1.0 is merged to trunk and tag 1.1.1.0 is created. Software is release to the client for final tests. Client approves it and the release goes for production with new functionality. Team 2 is up to date in it's 1.1b branch, Team 1 keeps apart from production updates. Team 1 finishes developing their new features and gets build 1.1a.0.23 approved by QA functional tests. Now Team 1 decides to rebase their work and merge the current trunk content to their 1.1a branch. They solve conflicts and run unit tests OK. Since version 1.1 was already released, they now copy their 1.1a branch to tag 1.2.0.24 and asks QA to rerun all planned tests. Few bug fixes later, client tests OK, build 1.2.0.28 becomes the new release for production. Changes applied to the trunk, branch 1.1a is deleted. Second fix package finishes and build 1.2.1.0 is released. Trunk is updated once again. Team 2 decides to stop development, rename its branch to 1.3 and rebases it with current trunk version. Next functional release will be 1.3 finishing all planned development for this software. Life goes on... What you think? -Mensagem original- De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Enviada em: sexta-feira, 29 de outubro de 2010 11:05 Para: 'lki...@dba.com.br' Cc: 'users@subversion.apache.org' Assunto: RE: Advice on process for web development CC-ing the list > -Original Message- > From: Luiz Guilherme Kimel [mailto:lki...@dba.com.br] > Sent: 29 October 2010 15:44 > To: Giulio Troccoli > Subject: RES: Advice on process for web development > > Giulio, > > I would recommend you a reference book for SCM patterns. Try > ADDISON WESLEY Software Configuration Management Patterns. It > has solutions > > Answering your questions, you need to stablish baselines for > your software. > Branches will have one baseline as their common start point, > as their "base". This base will usually be a stable version > of your software. Let's say your baseline is exactly your > current production release. What you're saying is that the branches should be created as copies of trunk at a specific revision, i.e. the production one. Have I understood correctly? > Sometimes your baseline will evolve. Maybe because your QA > team approved some new features for production, maybe because > you made urgent corrections. > If it's approved for production it will be your new baseline. > All branches from this baseline will need to be "rebased" > before releasing, they need to incorporate any production changes. So, basically, I need to merge changes in trunk from the previous "production" revision to the current "production" revision (which may not be HEAD at all) to the branches. > Your correction will be tested isolated, approved and merged > to your trunk for tagging and release. If your development > branches are based on the trunk,
Re: unexpected mergeinfo results (v1.6.13)
On Thu, Oct 28, 2010 at 4:40 PM, Wöster Benjamin wrote: > Hi all, > > > > I’m currently trying to clean up explicit mergeinfos that are scattered > throughout our repository. > > Some of these explicit mergeinfos were created because people used sparse > working copies and didn’t know about the impacts. > > So I’m trying to locate the pathes that contain non-inheritable mergeinfos, > check that those merged revisions didn’t affect the children of that path, > > and redo the merge with the –record-only option for that path. This way, I > hope I can eliminate the non-inheritable mergeinfos as first step of the > cleanup. > > > > I’ve attached a perl script, that will reproduce a sample environment (it > needs svn and svnadmin to be in your path). > > It creates (in your current working directory) a repository and a working > copy. The script creates some test data, creates a feature branch, > > simulates some work (including cherry-picking from trunk to the feature > branch) and at the end, it merges the branch back to the trunk. > > Last but not least, it creates a cleanup branch. > > > > > > This is the point where I am with my productive repository, and it turns > out, that the cherry-picked revisions cause the behavior I wouldn’t have > expected. > > The following is the session I use to reproduce the work till the point > where I’m unsure if svn does things right. > > > > # creating the test data > > c:\mergeinfo>mergeinfo_fixture.pl > > c:\mergeinfo>dir > > Verzeichnis von c:\mergeinfo > > > > 28.10.2010 20:33 . > > 28.10.2010 20:33 .. > > 28.10.2010 20:28 2.108 mergeinfo_fixture.pl > > 28.10.2010 20:33 repo > > 28.10.2010 20:33 wc > > > > # navigate to the cleanup branch > > c:\mergeinfo>cd wc\branches\cleanup > > > > # checking for the non-inheritable merge info > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 > > /branches/feat_1/folder_1:2-6* > > /trunk/folder_1:4* > > > > So here it is. My understanding of the mergeinfo and the mergeinfo elision > is, that once these revisions get merged into the children of that path, > > the explicit merge info should disappear. So I’m trying: > > > > > > (first with svn 1.6.12, which behaves the way I expected it to work) > > > > c:\mergeinfo\wc\branches\cleanup>svn –version > > svn, version 1.6.12 (r955767) > > > > c:\mergeinfo\wc\branches\cleanup>svn merge -r 3:4 --record-only > "^/trunk/folder_1" folder_1 > > c:\mergeinfo\wc\branches\cleanup>svn status > > M folder_1 > > > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 > > /branches/feat_1/folder_1:2-6* > > /trunk/folder_1:4 > > > > So we see: r4 is no longer been marked as non-inheritable, but since it > still contains other non-inheritable mergeinfos, > > the data is still stored as explicit mergeinfo. I’m fine with that. > > > > > > (now the same with the newer svn 1.6.13) > > > > c:\mergeinfo\wc\branches\cleanup>svn revert . -R > > Reverted 'folder_1' > > > > c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" > --version > > svn, Version 1.6.13 (r1002816) > > > > c:\mergeinfo\wc\branches\cleanup>"c:\Program Files\Subversion\bin\svn.exe" > merge -r 3:4 --record-only "^/trunk/folder_1" folder_1 > > c:\mergeinfo\wc\branches\cleanup>svn status > > M folder_1\file_1 > > M folder_1\file_2 > > M folder_1\file_3 > > > > c:\mergeinfo\wc\branches\cleanup>svn pg svn:mergeinfo folder_1 -R > > folder_1\file_1 - > > folder_1 - /branches/feat_1/folder_1:2-6* > > /trunk/folder_1:4* > > folder_1\file_2 - > > folder_1\file_3 – > > > > Now, this is what I don’t understand. I merged (well, recorded) the changes > of revision 4 into a fully recursive working copy. > > The result according to the new client is, that the revision was only merged > down to folder_1, not into its children. > > Those instead get an explicit, empty mergeinfo property set, which means: > “Nothing has been merged to me so far”. > > > > I’m unsure if this behavior is intended. It’s correct that none of the > changes would have ever touched those files, > > but didn’t I tell svn to record that the revisions should be marked as > merged? In my opinion, it simply refuses to do that (the 4* still exists), > > plus it adds more explicit mergeinfo to the childs (something I can’t > understand right now, but maybe it makes sense). > > > > So what do you think? Is this behavior intended or did something go wrong > between v1.6.12 and 1.6.13? > > Or maybe am I missing some important point? > > > > Thanks in advance! The asterisk at the end of the revision number list indicates that the revision list only applies to the current directory - i.e. it's non-recursive. BTW, I posted a similar Perl script to this mailing list some time ago. When done, you may want to look into the Subversion Hook Framework for a hook script that prevents recording merge into for lower level files and folders. -- Geoff Rowell ge
Re: RES: Advice on process for web development
On 10/29/2010 12:10 PM, Luiz Guilherme Kimel wrote: Let me try explain it better... Let's say I just built the first version of an application, so I don't currently have any branch, just the trunk where a small team of developers were working until now. Our last build was tagged as 1.0.0.54 meaning it's our 54 build of the 1.0 version. The QA team approved this build and it becomes our first release of the software. Tag 1.0.0.54 is our baseline which is equal to our trunk at that moment. Now we have two new modules to develop in parallel. The team will receive more people to speed up next releases, so we decided to start working with branches. Two new branches are created: /branches/1.1a and /branches/1.1b. Trunk is locked. Only reading is allowed. Developers are allowed to write only on branches. What do you gain by making 2 branches instead of continuing one line of development on the trunk and the one that would be disruptive to it on a branch? -- Les Mikesell lesmikes...@gmail.com
svn export bug in 1.6.13
Hi, I just ran across a bug in the 1.6.13 release. Historically, 'svn export $SVNROOT/$PATH .' has just exported the contents of $PATH into the current directory. Under 1.6.13, the client creates a subdir named after the last directory component of $PATH and puts the contents there. This change in behavior breaks some of our release scripts and we've been forced to downgrade to 1.6.12. # 1.6.13 [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N . Atrunk Atrunk/top.mk Exported revision 50141. # Replace 1.6.13 rpm with 1.6.12 [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N . A. Atop.mk Exported revision 50141. - cls
Re: svn export bug in 1.6.13
http://subversion.tigris.org/issues/show_bug.cgi?id=3727 Chris Seawood wrote on Fri, Oct 29, 2010 at 10:04:17 -0700: > Hi, > > I just ran across a bug in the 1.6.13 release. > > Historically, 'svn export $SVNROOT/$PATH .' has just exported the > contents of $PATH into the current directory. Under 1.6.13, the client > creates a subdir named after the last directory component of $PATH and > puts the contents there. This change in behavior breaks some of our > release scripts and we've been forced to downgrade to 1.6.12. > > # 1.6.13 > [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N . > Atrunk > Atrunk/top.mk > Exported revision 50141. > > # Replace 1.6.13 rpm with 1.6.12 > [cseaw...@localhost foo]$ svn export --force $SVNROOT/trunk -N . > A. > Atop.mk > Exported revision 50141. > > - cls
RES: RES: Advice on process for web development
Nothing if you don't have concurrent "new features" development lines. If you can predict serial updates, then you won't need to branch. It's the first option, it's less complex: one mainline of development, branching only for emergency corrections from production tags. But, if you have concurrent development efforts that can be stopped, change in priority, take long time to be validated by a client etc, then I think branching for feature and updating the trunk only with stable code that needs to be spread turns everything easier and cleaner. If you have many different clients for a single product, it may gets hard to know which new feature will be released first. Clients will not always obey to plans and clients may change their mind in what is priority and what is not. -Mensagem original- De: Les Mikesell [mailto:lesmikes...@gmail.com] Enviada em: sexta-feira, 29 de outubro de 2010 14:00 Para: users@subversion.apache.org Assunto: Re: RES: Advice on process for web development On 10/29/2010 12:10 PM, Luiz Guilherme Kimel wrote: > Let me try explain it better... > > Let's say I just built the first version of an application, so I don't > currently have any branch, just the trunk where a small team of developers > were working until now. Our last build was tagged as 1.0.0.54 meaning it's > our 54 build of the 1.0 version. The QA team approved this build and it > becomes our first release of the software. Tag 1.0.0.54 is our baseline > which is equal to our trunk at that moment. > > Now we have two new modules to develop in parallel. The team will receive > more people to speed up next releases, so we decided to start working with > branches. Two new branches are created: /branches/1.1a and /branches/1.1b. > Trunk is locked. Only reading is allowed. Developers are allowed to write > only on branches. What do you gain by making 2 branches instead of continuing one line of development on the trunk and the one that would be disruptive to it on a branch? -- Les Mikesell lesmikes...@gmail.com
RE: Moving to Subversion for PL-SQL development
Giulio, I'm not sure if I correctly understood all the details of your questions but I have been using Subversion in an environment that mostly consists of C/C++, Java and an Oracle Database for quite some time and would be happy to share my experience. >From my general perspective managing PL/SQL in a version control system is quite the same as managing any other sources. The real complex thing is how to manage and upgrade the different revisions/version of the database structure itself. In our environment each "shippable" (alpha, beta, production) version of our database structure (including PL/SQL) is tagged in Subversion. The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to create a new database and additionally contains the appropriate update scripts (typically a set of SQL Scripts executed in SQL*Plus) needed to update the last revision to this one. For an update we then use a custom developed application that determines the source revision of the database and to witch revision to update, extracts all the needed tags and executes the appropriate update scripts in each tagged revision in the proper order. I hope this helps a little. Cheers, Dieter > -Original Message- > From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > Sent: Friday, October 29, 2010 15:11 > To: users@subversion.apache.org > Subject: Moving to Subversion for PL-SQL development > > First of all let me tell you that I don't know much of how PL-SQL > development works so I might say something really obvious to you or > more likely just wrong. Please forgive me. > > I have a team that uses StarTeam as their VCS and we are now working on > moving the project to Subversion. We are planning to use an importer > for the initial load of the repository which seems to do what they want > (I'm not looking after that part). > > I have a problem though with their releasing process. > > As I understand it, a major release is formed by all the packages and > scripts, plus some table initialisation and sometime some data (I > presume for defaults and stuff like that). Minor releases are done with > patches which included only the packages that have changed from the > previous patch. > > So, if I want 5.4.0 (major release), I get everything. I unpack the > kit, install it, run it, whatever it take and I'm done. If I am already > on 5.4.0 and I want 5.4.3 (a minor release) I will be sent 3 patches: > to 5.4.1, then 5.4.2 and finally 5.4.3. Apparently I just need to unzip > them and I'm done. > > Now, I might not be clear in the above process, so if someone with more > experience with PL-SQL development and release wants to correct me, > please do. I know there isn't one way to do things, but it's more > likely that I understood wrong than we are doing it in a special way. > > Anyway, if I am right, I'm struggling to come up with a process using > Subversion. It seems they do not want to tag everything in trunk > because that would be like a major release (apparently it would include > those table and data things). Maybe we could re-organised the code to > separate the packages from the data and then we could tag the packages, > which is more what they want. And this way, to go to 5.4.3 I won't need > 5.4.1 and 5.4.2 at all, which in my opinion is even better. > > In the end what I am looking for with this email is some advice on how > to proceed from people with more experience than me in projects using > PL-SQL. > > Thanks > Giulio Troccoli > > > Linedata Limited > Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in > England and Wales No 3475006 VAT Reg No 710 3140 03 > >
Re: Moving to Subversion for PL-SQL development
On 10/29/2010 1:06 PM, Dieter Oberkofler wrote: Giulio, I'm not sure if I correctly understood all the details of your questions but I have been using Subversion in an environment that mostly consists of C/C++, Java and an Oracle Database for quite some time and would be happy to share my experience. From my general perspective managing PL/SQL in a version control system is quite the same as managing any other sources. The real complex thing is how to manage and upgrade the different revisions/version of the database structure itself. In our environment each "shippable" (alpha, beta, production) version of our database structure (including PL/SQL) is tagged in Subversion. The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to create a new database and additionally contains the appropriate update scripts (typically a set of SQL Scripts executed in SQL*Plus) needed to update the last revision to this one. For an update we then use a custom developed application that determines the source revision of the database and to witch revision to update, extracts all the needed tags and executes the appropriate update scripts in each tagged revision in the proper order. There's something called liquibase (http://www.liquibase.org) that is supposed to manage this for you. I don't know much about it other than that it is used by the OpenNMS project and run as an update step to fix schema changes between versions. -- Les Mikesell lesmikes...@gmail.com
RES: Moving to Subversion for PL-SQL development
Dieter, "For an update we then use a custom developed application that determines the source revision of the database and to witch revision to update, extracts all the needed tags and executes the appropriate update scripts in each tagged revision in the proper order" Sounds perfect! But how do you manage daily work on Oracle packages? Does your developers work in local Oracle instances or a shared development Oracle instance? Does your PL/SQL development tool integrates to SVN in some way? Could you describe it briefly? I'm interested in how you manage it. Thank you! -Mensagem original- De: Dieter Oberkofler [mailto:doberkofler.li...@gmail.com] Enviada em: sexta-feira, 29 de outubro de 2010 15:07 Para: 'Giulio Troccoli' Cc: users@subversion.apache.org Assunto: RE: Moving to Subversion for PL-SQL development Giulio, I'm not sure if I correctly understood all the details of your questions but I have been using Subversion in an environment that mostly consists of C/C++, Java and an Oracle Database for quite some time and would be happy to share my experience. >From my general perspective managing PL/SQL in a version control system is quite the same as managing any other sources. The real complex thing is how to manage and upgrade the different revisions/version of the database structure itself. In our environment each "shippable" (alpha, beta, production) version of our database structure (including PL/SQL) is tagged in Subversion. The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to create a new database and additionally contains the appropriate update scripts (typically a set of SQL Scripts executed in SQL*Plus) needed to update the last revision to this one. For an update we then use a custom developed application that determines the source revision of the database and to witch revision to update, extracts all the needed tags and executes the appropriate update scripts in each tagged revision in the proper order. I hope this helps a little. Cheers, Dieter > -Original Message- > From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > Sent: Friday, October 29, 2010 15:11 > To: users@subversion.apache.org > Subject: Moving to Subversion for PL-SQL development > > First of all let me tell you that I don't know much of how PL-SQL > development works so I might say something really obvious to you or > more likely just wrong. Please forgive me. > > I have a team that uses StarTeam as their VCS and we are now working on > moving the project to Subversion. We are planning to use an importer > for the initial load of the repository which seems to do what they want > (I'm not looking after that part). > > I have a problem though with their releasing process. > > As I understand it, a major release is formed by all the packages and > scripts, plus some table initialisation and sometime some data (I > presume for defaults and stuff like that). Minor releases are done with > patches which included only the packages that have changed from the > previous patch. > > So, if I want 5.4.0 (major release), I get everything. I unpack the > kit, install it, run it, whatever it take and I'm done. If I am already > on 5.4.0 and I want 5.4.3 (a minor release) I will be sent 3 patches: > to 5.4.1, then 5.4.2 and finally 5.4.3. Apparently I just need to unzip > them and I'm done. > > Now, I might not be clear in the above process, so if someone with more > experience with PL-SQL development and release wants to correct me, > please do. I know there isn't one way to do things, but it's more > likely that I understood wrong than we are doing it in a special way. > > Anyway, if I am right, I'm struggling to come up with a process using > Subversion. It seems they do not want to tag everything in trunk > because that would be like a major release (apparently it would include > those table and data things). Maybe we could re-organised the code to > separate the packages from the data and then we could tag the packages, > which is more what they want. And this way, to go to 5.4.3 I won't need > 5.4.1 and 5.4.2 at all, which in my opinion is even better. > > In the end what I am looking for with this email is some advice on how > to proceed from people with more experience than me in projects using > PL-SQL. > > Thanks > Giulio Troccoli > > > Linedata Limited > Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in > England and Wales No 3475006 VAT Reg No 710 3140 03 > >
RES: Moving to Subversion for PL-SQL development
Wow! This sounds really very good. I will try it here! PS: OpenNMS also looks a very nice finding. Thank you! (twice) -Mensagem original- De: Les Mikesell [mailto:lesmikes...@gmail.com] Enviada em: sexta-feira, 29 de outubro de 2010 15:19 Para: users@subversion.apache.org Assunto: Re: Moving to Subversion for PL-SQL development There's something called liquibase (http://www.liquibase.org) that is supposed to manage this for you. I don't know much about it other than that it is used by the OpenNMS project and run as an update step to fix schema changes between versions. -- Les Mikesell lesmikes...@gmail.com
RE: Moving to Subversion for PL-SQL development
Luiz, > Sounds perfect! But how do you manage daily work on Oracle packages? > Does your developers work in local Oracle instances or a shared > development Oracle instance? There is no simple answer to this and it really depends on how "different" a database version gets. I'm not sure, if I'm able to describe this but let me try: Typically every developer has its local Database Instance that in our case are schemas on a single server and there is a master schema that always hold a "consistent snapshot" and most often is the same as the tagged revision. If there are major changes that may be needed or affect other developers in the team, there is a branch that hold the individual changes and the changes will be merged into the main trunk when they should be made available to others. Our update application has a special "development" update option that instead of moving from one tagged revision to the next one also allows to "just" run a set of update scripts currently available in the trunk of our database repository and this would then allow the team members to eventually (if needed) upgrade their local database to some "intermediate" revision. > Does your PL/SQL development tool integrates to SVN in some way? We mostly use a simple editor (or PlEdit) to edit SQL and PL/SQL scripts and then run all our scripts with good old SQL*Plus, so there is no SVN integration. We have spend quite some time to figure out how to integrate some kind of locking mechanism in our toolset but at the end found out that there is little out there and we do not really need it as much as we originally would have expected. There is a lot less conflicts that we anticipated because the database design is (at least in our organization) a rather centralized type of work. We generally do not use any tools that integrate SVN because we very much like using the SVN command line or TortoiseSVN. Cheers, Dieter > -Original Message- > From: Luiz Guilherme Kimel [mailto:lki...@dba.com.br] > Sent: Friday, October 29, 2010 21:25 > To: users@subversion.apache.org > Subject: RES: Moving to Subversion for PL-SQL development > > Dieter, > > "For an update we then use a custom developed application that > determines the source revision of the database and to witch revision to > update, extracts all the needed tags and executes the appropriate > update scripts in each tagged revision in the proper order" > > Sounds perfect! But how do you manage daily work on Oracle packages? > Does your developers work in local Oracle instances or a shared > development Oracle instance? Does your PL/SQL development tool > integrates to SVN in some way? > > Could you describe it briefly? I'm interested in how you manage it. > > Thank you! > > > -Mensagem original- > De: Dieter Oberkofler [mailto:doberkofler.li...@gmail.com] > Enviada em: sexta-feira, 29 de outubro de 2010 15:07 > Para: 'Giulio Troccoli' > Cc: users@subversion.apache.org > Assunto: RE: Moving to Subversion for PL-SQL development > > Giulio, > > I'm not sure if I correctly understood all the details of your > questions but I have been using Subversion in an environment that > mostly consists of C/C++, Java and an Oracle Database for quite some > time and would be happy to share my experience. > > From my general perspective managing PL/SQL in a version control system > is quite the same as managing any other sources. > > The real complex thing is how to manage and upgrade the different > revisions/version of the database structure itself. > In our environment each "shippable" (alpha, beta, production) version > of our database structure (including PL/SQL) is tagged in Subversion. > The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to > create a new database and additionally contains the appropriate update > scripts (typically a set of SQL Scripts executed in SQL*Plus) needed to > update the last revision to this one. > For an update we then use a custom developed application that > determines the source revision of the database and to witch revision to > update, extracts all the needed tags and executes the appropriate > update scripts in each tagged revision in the proper order. > > I hope this helps a little. > > Cheers, > Dieter > > > > -Original Message- > > From: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] > > Sent: Friday, October 29, 2010 15:11 > > To: users@subversion.apache.org > > Subject: Moving to Subversion for PL-SQL development > > > > First of all let me tell you that I don't know much of how PL-SQL > > development works so I might say something really obvious to you or > > more likely just wrong. Please forgive me. > > > > I have a team that uses StarTeam as their VCS and we are now working > > on moving the project to Subversion. We are planning to use an > > importer for the initial load of the repository which seems to do > what > > they want (I'm not looking after that part). > > > > I have a problem thoug
Observed changes didn't match count
The Pure project is trying to switch from Subversion to Mercurial, and are having trouble with svnsync. http://groups.google.com/group/pure-lang/msg/bf588ebe14d6fb14 On revision 2967, it gives the message "Observed changes didn't match count", and I get the same message when just doing an "svn log -v" on that revision: $ svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk svn: Observed changes didn't match count $ "svn log" without "-v" works fine, as does "svn diff". Google searching for this error message yields only one other occurrence, which was not really solved. I'm unsure what we should try from here. Possibly this error is unique to Google Code's Subversion backend, but still I would have expected others to have run into it. Any suggestions?
Re: Observed changes didn't match count
Short version: it's a bug in Google's backend, and I can reproduce it with neon but not with serf. (more below) Ryan Schmidt wrote on Fri, Oct 29, 2010 at 16:24:20 -0500: > The Pure project is trying to switch from Subversion to Mercurial, and are > having trouble with svnsync. > > http://groups.google.com/group/pure-lang/msg/bf588ebe14d6fb14 > > On revision 2967, it gives the message "Observed changes didn't match count", > and I get the same message when just doing an "svn log -v" on that revision: > > $ svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk > svn: Observed changes didn't match count [[[ % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk --config-option servers:global:http-library=serf % echo $? 0 % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk --config-option servers:global:http-library=neon ... subversion/libsvn_ra_neon/util.c:773: (apr_err=160004) svn: Observed changes didn't match count % echo %? 1 % ./tools/dev/which-error.py 160004 00160004 SVN_ERR_FS_CORRUPT % $svn --version | head -n2 svn, version 1.7.0 (dev build) compiled Oct 27 2010, 15:38:01 % ]]] > $ > > "svn log" without "-v" works fine, as does "svn diff". > > Google searching for this error message yields only one other occurrence, > which was not really solved. > > I'm unsure what we should try from here. Possibly this error is unique > to Google Code's Subversion backend, The error code confirms your suspicion. Furthermore, the word "Observed" doesn't appear in Subversion's source code. > but still I would have expected > others to have run into it. Any suggestions? > > >
Re: Observed changes didn't match count
On Oct 29, 2010, at 17:11, Daniel Shahaf wrote: > Short version: it's a bug in Google's backend, and I can reproduce it > with neon but not with serf. > % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk > --config-option servers:global:http-library=serf > > % echo $? > 0 > % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk > --config-option servers:global:http-library=neon > ... > subversion/libsvn_ra_neon/util.c:773: (apr_err=160004) > svn: Observed changes didn't match count > % echo %? > 1 > % ./tools/dev/which-error.py 160004 > 00160004 SVN_ERR_FS_CORRUPT > % $svn --version | head -n2 > svn, version 1.7.0 (dev build) > compiled Oct 27 2010, 15:38:01 > % I agree using serf instead of neon makes the error message go away. But it also doesn't actually show the list of files affected by the commit like it should. See "svn diff --summarize -r2967" for all the files that should be shown there. Also, even when I change http-library to serf in the servers config file, svnsync still shows the "Observed changes didn't match count" error. Does svnsync not use this library setting? >> I'm unsure what we should try from here. Possibly this error is unique >> to Google Code's Subversion backend, > > The error code confirms your suspicion. Furthermore, the word > "Observed" doesn't appear in Subversion's source code. I suppose we should report the problem to Google Code and hope they can uncorrupt the repository somehow? Apparently a couple dozen subsequent revisions see the same error, through r2993.
Re: Observed changes didn't match count
Ryan Schmidt wrote on Fri, Oct 29, 2010 at 18:26:25 -0500: > On Oct 29, 2010, at 17:11, Daniel Shahaf wrote: > > > Short version: it's a bug in Google's backend, and I can reproduce it > > with neon but not with serf. > > > % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk > > --config-option servers:global:http-library=serf > > > > % echo $? > > 0 > > % $svn log -v -r2967 http://pure-lang.googlecode.com/svn/trunk > > --config-option servers:global:http-library=neon > > ... > > subversion/libsvn_ra_neon/util.c:773: (apr_err=160004) > > svn: Observed changes didn't match count > > % echo %? > > 1 > > % ./tools/dev/which-error.py 160004 > > 00160004 SVN_ERR_FS_CORRUPT > > % $svn --version | head -n2 > > svn, version 1.7.0 (dev build) > > compiled Oct 27 2010, 15:38:01 > > % > > I agree using serf instead of neon makes the error message go away. > But it also doesn't actually show the list of files affected by the > commit like it should. See "svn diff --summarize -r2967" for all the > files that should be shown there. > More specifically, it behaves as if there are no relevant revisions to show: [[[ % $svn log -vr100 http://svn.eu.apache.org/repos/asf/subversion % $svn log -vr100 http://svn.eu.apache.org/repos/asf r100 | yonik | 2010-09-22 16:48:10 +0200 (Wed, 22 Sep 2010) | 1 line Changed paths: M /lucene/dev/trunk/solr/CHANGES.txt M /lucene/dev/trunk/solr/src/java/org/apache/solr/search/FunctionQParser.java M /lucene/dev/trunk/solr/src/java/org/apache/solr/search/QueryParsing.java M /lucene/dev/trunk/solr/src/test/org/apache/solr/search/FunctionQParserTest.java M /lucene/dev/trunk/solr/src/test/org/apache/solr/search/function/TestFunctionQuery.java SOLR-2128: full param substitution for function queries % ]]] There shouldn't be any authz restrictions on this repository, right? > Also, even when I change http-library to serf in the servers config > file, svnsync still shows the "Observed changes didn't match count" > error. Does svnsync not use this library setting? > Examining the code shows that the apr_hash_t *config is passed down to svn_ra_open4(), and upon trying I cannot reproduce this: [[[ % $svnsync init http://localhost:8081/t/{r2,r1} DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV protocol using serf.' url='http://localhost:8081/t/r2' DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV protocol using serf.' url='http://localhost:8081/t/r1' Copied properties for revision 0. % mkdir cfg % cat > cfg/servers [global] http-library = neon % $svnsync sync http://localhost:8081/t/r2 --config-dir cfg DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV protocol using Neon.' url='http://localhost:8081/t/r2' DBG: ra_loader.c: 493: vtable='Module for accessing a repository via WebDAV protocol using Neon.' url='http://localhost:8081/t/r1' Transmitting file data Committed revision 1. Copied properties for revision 1. ]]] > > >> I'm unsure what we should try from here. Possibly this error is unique > >> to Google Code's Subversion backend, > > > > The error code confirms your suspicion. Furthermore, the word > > "Observed" doesn't appear in Subversion's source code. > > I suppose we should report the problem to Google Code and hope they > can uncorrupt the repository somehow? Yes. SVN_ERR_FS_CORRUPT justifies reporting this to the Google admins. > Apparently a couple dozen > subsequent revisions see the same error, through r2993. >