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.
Received on 2012-07-26 22:17:04 CEST