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?
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.
To avoid problems caused by mixed-revision working copies, always perform
server-side copies, i.e. pass only URL arguments to 'svn copy'.
Received on 2012-07-26 19:26:29 CEST