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 <stsp_at_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.
>
Received on 2012-07-26 23:48:06 CEST