On Thu, Jul 26, 2012 at 08:58:24PM +0200, Kiren Pillay wrote: > Thanks Stefan, > > Is there no way out of this. I'm thinking that maybe I should take the > current code out of trunk and create a brand new repository. I don't want > our past mistakes to haunt us for the rest of the project :/ > > Is there an alternative way to fix this?
Well, if what you've committed now is your desired merge result, then that's fine. This won't haunt you forever if you start using the proper merge commands in the future. It sounds like you mainly want the sync and reintegrate merges as explained in http://subversion.apache.org/docs/svn-merge.txt Just remember which direction you're merging in. If merging from trunk to a branch, use the "sync" type merge. If merging a branch back into trunk (or into whichever other branch it was branched off from) use the "reintegrate" type of merge. If you stick to that there should be no spurious conflicts. > I'm doing an update merge, which is trunk into feature branch > svn://bcx-svn/ > vodacom.za/pams/server/branches/v1-4-3-AM-CR3159-BatchActivations<http://vodacom.za/pams/server/branches/v1-4-3-AM-CR3159-BatchActivations/business_services/main_servlet/src/main/resources/testconfigs/pams.properties>/ > > > The kind of cross-branch copying in the above commit is usually not > > recommended. > > Okay, this is most likely the source of our problem. Is there any way to > make svn forget/ignore this? No. The history has been recorded as it happened. But going forward you can start to avoid this problem. > > To avoid problems caused by mixed-revision working copies, always perform > > server-side copies, i.e. pass only URL arguments to 'svn copy'. > > > > Okay, what I've been doing when I have tree conflicts is to copy missing > files into my working copy from the merge source. Are you saying this is > incorrect? I've written a blog where it shows how I resolved tree > conflicts. Are the steps there correct? ( > http://www.kirenpillay.blogspot.com/2012/07/svn-merge-tree-conflict-resolution.html The most important thing is that you could always commit the desired merge result. So the state of the code on the branch is in good shape. That's what matters most. You didn't describe why the conflicts you ran into occurred. If you dig into the histories of both branches you should be able to find a set of conflicting changes that clearly indicate a conflict. This is really the first thing you need to figure out in a tree conflict scenario: What did people do to make this happen? Where is the conflict of intentions in the changes that were made? If you cannot find a reason for the conflict then it is likely a spurious one. Spurious conflicts can happen because you're not using the correct merge command invocation, especially if you forget to pass --reintegrate when you merge a branch back into its parent branch. Or it could be a false positive tree conflict. These can happen because of insufficiencies in Subversion that make it hard to tell apart some conflict scenarios from some non-conflict scenarios. E.g. a rename will currently always look like a deletion during tree conflict detection so Subversion so it might flag a conflict even if both sides intended to delete the object (rather than one side deciding to rename the object while the other side wants to delete it). We're trying to fix these issues -- they are clearly a problem in the software rather than a usage problem. The 'local missing vs. incoming edit' conflicts you describe can happen if: - You delete a file which existed in the common ancestor of both branches, and the file is later modified on trunk and you merge this modification. in this case you probably want to keep the file deleted (or you might decide to resurrect it, in which case the best approach would be to first revert the entire working copy, undo the file's deletion on the local branch and commit (see http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo), and then repeat the first merge (which should now not conflict anymore). - After your branch is created, a new file is created on trunk in revision A and later modified in revision B. You only merge revision B which means the file is not created on your branch before the merge tries to apply the modification. In this case you should probably also merge revision A. A normal sync merge of the 'svn merge ^/trunk' variety will always do this. It might help if you create a small test repository to learn more about how Subversion behaves when it encounters tree conflicts. You can create a local test repository like this: svnadmin create /tmp/repos and access it via a file:// URL: svn checkout file:///tmp/repos wc Now you can create a trunk and then a branch, intentionally produce some tree conflicts and observe what happens. It might be easier to understand Subversion's behaviour when observed in a small and controlled fashion, rather than in a busy production repository.