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? On Thu, Jul 26, 2012 at 7:25 PM, Stefan Sperling <s...@elego.de> wrote: > On Thu, Jul 26, 2012 at 06:51:36PM +0200, Kiren Pillay wrote: > > Aslo, I am interested in why this V1-1-1-preprod branch causes the > > conflict. Could you maybe have a look at this snippet of the SVN log > where > > I suspect things went wrong? I think the copy from v1-1-0 to trunk is the > > issue? > > The log itself provides only part of the picture of what's going on > during the merge. It shows the history of the branch, but tells us > nothing about the actual merge operation that runs into a conflict. > > What exactly are you doing to merge this branch with which other branch? > 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>/ > > That said, the following looks suspicious: > > > update to 1.2.0 final > > ------------------------------------------------------------------------ > > r6933 | richard | 2011-06-13 14:49:04 +0200 (Mon, 13 Jun 2011) | 1 line > > Changed paths: > > A /pams/server/trunk (from /pams/server/branches/V1-1-1-preprod:6896) > > R /pams/server/trunk/business_services/main_servlet (from > > /pams/server/branches/V1-1-1-preprod/business_services/main_servlet:6927) > > D > > > /pams/server/trunk/core/ppfe-connectors/src/main/resources/META-INF/spring/poolmanager.properties > > D > > > /pams/server/trunk/core/ppfe-connectors/src/test/resources/poolmanager.properties > > > > Copy from 1.1.1 PREPROD deployed 2011/06/10 > > It seems the developer created a 'trunk' directory within /pams/server/ > by copying the root of the V1-1-1-preprop branch there. This is not > usual practice. A branch would usually be reintegrated back into > its parent branch, which would then in turn be reintegrated back, etc. > until the desired changes flow back into trunk -- the directory from which > all other branches (or "copies" in Subversion's own terms) originate. > > The kind of cross-branch copying in the above commit is usually not > recommended. There are cases where such a strategy is needed and useful. > But such a strategy should only be considered if best-practice > recommendations cannot be made to work because of workflow or process > restrictions specific to your organisation. > > The source of the copy was probably a mixed-revision working copy > (see here for what this means: > > http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs > ) > This would explain the replacement of the 'main_servlet' subdirectory > of the newly added 'trunk' dir within the same commit. > When this commit was processed, Subversion first performed a server-side > recursive copy of 'business_services@6896', followed by the deletion of > the > 'main_servlet@6896' child, and an addition of the 'main_servlet@6927' > child, > in order to accurately represent the mixed-revision working copy state > that was committed to the repository (which, in contrast to the working > copy, has no concept of mixed-revisionness, so it has to reflect the > mixed-revision state via replacements). > This is not unusual but rarely desired. It is a side-effect of the > approach the developer took to move changes between branches. > If this revision is merged elsewhere it will cause a replacement > in the merge target, which can cause a tree conflict. > Okay, this is most likely the source of our problem. Is there any way to make svn forget/ignore this? > > 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 ) Regards Kiren
