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 shoul
RE: Merge of rename only merged deletion, not addition - file lost
> From: jcor...@gmail.com > Date: Wed, 12 Dec 2012 18:57:28 +0100 > Subject: Re: Merge of rename only merged deletion, not addition - file lost > To: gaff...@live.com > CC: users@subversion.apache.org > > 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? The client is TortoiseSVN, some 1.6 version. (The person in question is on vacation now, so I can not ask him.) The server is Subversion 1.6.6. > > [ 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. User error is of course a possible explanation. But we hold it unlikely. The developer has been working within SVN for more than four years now, and is experienced with merging. And nothing unusual happened during the merge. > 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. As already said, we are not aware of anything like this happening, in this part of the tree at least. A somewhat related question: When one re-integrates a branch, does Subversion merge back the commits, or does it merge the difference between the branch and the trunk? With kind regards Asbjørn
Externals within the same repository
Assume the following situation: There is a repository my_repo, structured like this: my_repo my_repo/trunk my_repo/trunk/a my_repo/trunk/a/file.h my_repo/trunk/b where my_repo/trunk/b has an svn:external to import the contents of my_repo/a. That is, b will have the contents of a external-ed in. Is this valid and sound SVN? With kind regards Asbjørn Sæbø _ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail®. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009
File externals before subversion 1.6
It seems, in one of our repositories, that Someone(TM) has been using svn:externals to include single files. This was done with version 1.4 of the SVN server, and it seems to have worked, even though I thought single file externals was first implemented for server version 1.6. How can this be? With kind regards Asbjørn Sæbø _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx
RE: File externals before subversion 1.6
> From: gaff...@live.com > To: users@subversion.apache.org > Subject: File externals before subversion 1.6 > Date: Mon, 25 Jan 2010 15:17:17 +0100 > > > It seems, in one of our repositories, that Someone(TM) has been > using svn:externals to include single files. This was done with > version 1.4 of the SVN server, and it seems to have worked, even > though I thought single file externals was first implemented for > server version 1.6. How can this be? Or is the svn:exernals something that is handled by the client? (We did have version 1.6 of the client, though.) Asbjørn _ Windows Live: Keep your friends up to date with what you do online. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_1:092010
RE: Externals within the same repository
> Date: Mon, 25 Jan 2010 09:32:49 -0500 > Subject: Re: Externals within the same repository > From: andy.l...@gmail.com > To: gaff...@live.com > CC: users@subversion.apache.org > > On Mon, Jan 25, 2010 at 09:14, Asbjørn Sæbø wrote: >> >> Assume the following situation: There is a repository my_repo, structured >> like this: >> >> my_repo >> my_repo/trunk >> my_repo/trunk/a >> my_repo/trunk/a/file.h >> my_repo/trunk/b >> >> where my_repo/trunk/b has an svn:external to import the contents of >> my_repo/a. >> That is, b will have the contents of a external-ed in. >> >> Is this valid and sound SVN? > > Yes, just be careful to avoid any recursive externals - having an > external in a pointing at b, while having an external in b pointing at > a, would probably result in your WC filling all available disk space. > Last I knew, Subversion did not check for recursion in externals. OK. But it does seem a bit weird, though. When doing a fresh check out of this, all these "internal externals" do show up as "merged" in the check out log. As TortoiseSVN presents it: - External C:\asa\my_repotrunk\a\file.h Merged C:\asa\my_repotrunk\a\file.h Since this was a clean check out, there should not really be any merging going on, so this message seems a bit confusing. Any comments? Asbjørn _ Keep your friends updated—even when you’re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010
