Subversion Exception!
--- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.10\ext\subversion\subversion\libsvn_wc\update_editor.c' line 1583: assertion failed (action == svn_wc_conflict_action_edit || action == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) --- OK --- Thanks, Ravi +1 610.205.8772
Re: Subversion Exception!
Ravi Kalyan Chakravarthy writes: > In file > 'D:\Development\SVN\Releases\TortoiseSVN-1.7.10\ext\subversion\subversion\libsvn_wc\update_editor.c' > line 1583: assertion failed (action == svn_wc_conflict_action_edit || action > == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace) Did you add or delete the svn:special property? If so then it's probably http://subversion.tigris.org/issues/show_bug.cgi?id=4091 and it should be fixed in the upcoming Subversion 1.7.8. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Merge of rename only merged deletion, not addition - file lost
Dear TortoiseSVNers, We have just seen a case where a file has been lost as a combination of renaming and merging. We must understand how this could happen, so that we can avoid similar situations in the future. What happened: 1 Our "product branch" (think of it as our trunk) was branched, to a branch called the "active signal" branch. 2 A file was renamed in the product branch. 3 The rename was propagated to the active signal branch as part of a merge to keep the branch in sync with the product branch. 4 The file was renamed again in the product branch 5 In the next merge to the active signal branch, only the deletion of the old file was propagated. The corresponding addition of the file with the new name did not happen. (Remember that this is done as a single commit.) 6 The active signal branch was reintegrated to the product branch. As a result of this, the file with its new name in the product branch was deleted. As a result, this file was lost from the head of the repository. For more details, see excerpts from the relevant commits below. Questions: * Why did the merge in step 5) above only merge the deletion, not the addition? * Why did the reintegration in 6) remove the existing (added) file? Please Cc: me on any answers, as I am currently not subscribed to the list. With kind regards Asbjørn Sæbø Excerpts from commits. The file(s) in question are /verification/branches/products/S110_nRF51822/doc/test_result/030_system_level_test_documentation.dox /verification/branches/products/S110_nRF51822/doc/test_result/030_system_test_level.dox (Copy from path: == 1) 6095 - Active signal branch branched off from product branch Revision: 6095 Author: nvlsi\hael Date: 29. november 2012 16:33:05 Message: [...] Added : /verification/branches/development/DRGN-740_active_signal (Copy from path: /verification/branches/products/S110_nRF51822, Revision, 6075) = 2) 6132 - Rename file in product branch Revision: 6132 Author: nvlsi\svag Date: 6. desember 2012 11:53:28 Message: [...] [...] Added : /verification/branches/products/S110_nRF51822/doc/test_result/030_system_level_test_documentation.dox (Copy from path: /verification/branches/products/S110_nRF51822/doc/test_result/030_tp_report.dox, Revision, 6121) Deleted : /verification/branches/products/S110_nRF51822/doc/test_result/030_tp_report.dox [...] = 3) 6186: Merge product branch to active signal branch to keep in sync Revision: 6186 Author: nvlsi\vewe Date: 10. desember 2012 12:58:35 Message: [...] Merge in changes from product branch [...] [...] Added : /verification/branches/development/DRGN-740_active_signal/doc/test_result/030_system_level_test_documentation.dox (Copy from path: /verification/branches/products/S110_nRF51822/doc/test_result/030_system_level_test_documentation.dox, Revision, 6158) Deleted : /verification/branches/development/DRGN-740_active_signal/doc/test_result/030_tp_report.dox [...] == 4) 6190 - Rename of a file in the product branch Revision: 6190 Author: nvlsi\svag Date: 10. desember 2012 14:54:24 Message: [...] Renamed a dox-file. Deleted : /verification/branches/products/S110_nRF51822/doc/test_result/030_system_level_test_documentation.dox Added : /verification/branches/products/S110_nRF51822/doc/test_result/030_system_test_level.dox (Copy from path: /verification/branches/products/S110_nRF51822/doc/test_result/030_system_level_test_documentation.dox, Revision, 6132) == 5) 6245 - Merge product branch to active signal branch to keep in sync Revision: 6245 Author: nvlsi\sac Date: 11. desember 2012 17:51:16 Message: [...] merged the product branch [...] to active signal branch [...] Modified : /verification/branches/development/DRGN-740_active_signal Deleted : /verification/branches/development/DRGN-740_active_signal/doc/test_result/030_system_level_test_documentation.dox Modified : /verification/branches/development/DRGN-740_active_signal/framework/builds/DragoonTools.manifest [...] ! Note that only the deletion from 6190 was merged, not the addition of the renamed file 6) 6279 - Reintegrate active signal branch to product branch Revision: 6279 Author: nvlsi\sac Date: 12. desember 2012 13:38:03 Message: [...] Reintegrate active signal branch to product branch Modified : /verification/branches/products/S110_nRF51822 Deleted : /verification/branches/products/S110_nRF51822/doc/test_result/030_system_test_level.dox Modified : /verification/branches/products/S110_nRF51822/doc/verification/appendix_categorization_labels.dox [...] ! Note that the file renamed in 6190, that should have been added to
Re: Merge of rename only merged deletion, not addition - file lost
On Wed, Dec 12, 2012 at 4:33 PM, Asbjørn Sæbø wrote: > > > Dear TortoiseSVNers, > > We have just seen a case where a file has been lost as a combination > of renaming and merging. We must understand how this could happen, so > that we can avoid similar situations in the future. First important question is: which version of (Tortoise)SVN was being used on the clients which performed the actions below? And the server? [ snip ] > == > > 5) 6245 - Merge product branch to active signal branch to keep in sync > > Revision: 6245 > Author: nvlsi\sac > Date: 11. desember 2012 17:51:16 > Message: > [...] merged the product branch [...] to active signal branch > > [...] > Modified : /verification/branches/development/DRGN-740_active_signal > Deleted : > /verification/branches/development/DRGN-740_active_signal/doc/test_result/030_system_level_test_documentation.dox > Modified : > /verification/branches/development/DRGN-740_active_signal/framework/builds/DragoonTools.manifest > [...] > > ! Note that only the deletion from 6190 was merged, not the addition of > the renamed file > One possible explanation could be "user error". It's possible that the user who carried out this merge, in his working copy, deleted the file /verification/branches/development/DRGN-740_active_signal/doc/test_result/030_system_test_level.dox from his working copy, prior to committing the merge result to the repository. In that case, the user does something to the merge result before committing it (this can be seen as a form of "merge conflict resolution" done by the user). This could be unintended, for example if the user got a tree conflict on that file, and didn't really know how to resolve it, and finally ended up deleting it. But it can also be perfectly reasonable, for example if the user saw some "semantic conflict" (not flagged automatically, because on a file / line level everything is ok), and the user then decides to get rid of this file. It's just a possibility. The only thing you can do against that is 1) making sure people (or colleagues) review what they are committing, and 2) running some continuous integration build on your branch to catch the error early. -- Johan
Re: Relative Revision on Relative Path External
Hello again, I just noticed my previous email got somewhat scrambled. The idea was to have notation like the following ../../common/module1@RELATIVE module1 in order to peg an external to the revision of the folder owning the the external property. The reason why I would like such a feature is because we have a product that gets packaged with various plugins. Each plugin is independently tested by QA. We have a branch call "staging" with is pretty much a folder with external properties. Our external property on this "staging" folder looks something like this https://svn.ingenius.com:8443/svn/ICE/trunk/Build@2483 Build https://svn.ingenius.com:8443/svn/ICE/trunk/Server@2483 Server https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/TypeA/Plugin1@2483 Plugins/TypeA/Plugin1 https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/TypeB/Plugin1@2486 Plugins/TypeA/Plugin1 https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/Plugins/TypeC/Plugin1@2509 Plugins/TypeC/Plugin1 https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/Plugins/TypeC/Plugin2@2310Plugins/TypeC/Plugin2 https://svn.ingenius.com:8443/svn/ICE/trunk/Plugins/Plugins/TypeC/Plugin3@2520Plugins/TypeC/Plugin3 https://svn.ingenius.com:8443/svn/ICE/trunk/Setup@2483 Setup https://svn.ingenius.com:8443/svn/ICE/trunk/Tools/ToolA@2483 Tools/ToolA https://svn.ingenius.com:8443/svn/ICE/trunk/Tools/ToolB@2483 Tools/ToolB https://svn.ingenius.com:8443/svn/ICE/trunk/Tools/ToolC@2483 Tools/ToolC This allows us to bring in the various components at their latest general QA accepted revision and makes for an incredibly convenient means to manage releases. The idea being that we simply move the peg revision on a plugin in order to include the latest QA approved plugin in a release candidate build. After QA approved the candidate we simply tag the staging branch as a release. The problem is that for this to work I first have to peg all the relative externals of a plugin on the trunk. Then peg that revision for "staging" so that the externals of that external are exported at the right revision. Then unpeg the trunk again so that development occurring on trunk gets the head revision. This is very cumbersome. Branching the entire trunk to peg the relatively path externals on the plugins is also cumbersome. Allowing for a RELATIVE peg on relative externals would a welcome addition. Here are the two links I was able to find were some other folks are looking for a similar solution to meet their needs. http://stackoverflow.com/questions/13297244/svn-externals-and-revision-association http://www.svnforum.org/threads/41345-revision-inheritage-in-svn-externals Thanks, Stefan On Tue, Dec 11, 2012 at 4:14 AM, Daniel Shahaf wrote: > Stefan Scherer wrote on Mon, Dec 10, 2012 at 16:09:47 -0500: > > I would like to be able to peg in product to a particular revision > and > > have and > > be of that same revision without having to maintain the peg > > at trunk/plugin/p1/EXTERNALS which would have to > > be constantly moving. > > > > > > > http://stackoverflow.com/questions/13297244/svn-externals-and-revision-association > > > http://www.svnforum.org/threads/41345-revision-inheritage-in-svn-externals > > > > How about a new feature to allow > > > > ../../common/module1@R <../../common/module1@relative>ELATIVE module1 > > > > or similar in the external definition. > > > > +1 > > > > Thanks, > > Stefan >
Re: Relative Revision on Relative Path External
On Wed, Dec 12, 2012 at 02:13:01PM -0500, Stefan Scherer wrote: > The idea being that we simply move the peg revision on a plugin in order to > include the latest QA approved plugin in a release candidate build. > After QA approved the candidate we simply tag the staging branch as a > release. > > The problem is that for this to work I first have to peg all the relative > externals of a plugin on the trunk. > Then peg that revision for "staging" so that the externals of that external > are exported at the right revision. > Then unpeg the trunk again so that development occurring on trunk gets the > head revision. > > This is very cumbersome. To do this in a single commit, you can get a fresh working copy of trunk, and pin down peg revs in svn:externals properties in this working copy. Next, copy this working copy to the staging location in the repository: cd working-copy svn copy . https://svn.ingenius.com::8443/svn/ICE/staging/foo Or use the ^/ short hand notation: cd working-copy svn copy . ^/ICE/staging/foo In windows cmd.exe you'll to type ^^/ instead: svn copy . ^^/ICE/staging/foo because ^ is a special character there. The staging branch/tag will be created as a server-side copy of trunk, plus modifications to svn:externals properties you made in the working copy.
