Thanks Stefan, will try out the test repo. Your help is really appreciated :)
Best Regards Kiren On Thu, Jul 26, 2012 at 10:16 PM, Stefan Sperling <s...@elego.de> wrote: > 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. >