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 <stsp_at_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_at_6896', followed by the deletion of
> the
> 'main_servlet_at_6896' child, and an addition of the 'main_servlet_at_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
Received on 2012-07-26 20:58:57 CEST