Ancestrally Related Error Message

[C M]

Hello,

Code for a new development effort was imported into a developer’s branch.

Now we want merge his changes to trunk (which is currently empty).

I tried the merge from both the command line and the Tortoise GUI and keep running into the “…must be ancestrally related…” message.I also tried the "ignore ancestry" option via the GUI.

One, I don't understand why SVN thinks there is even an ancestral relationship betweeen the two locations?

Two, how can I do to get around this error message?

Amad

 

 

 

[Bob Archer]

> Hello,
> Code for a new development effort was imported into a developer's branch.
> Now we want merge his changes to trunk (which is currently empty).
> I tried the merge from both the command line and the Tortoise GUI and keep

> running into the "...must be ancestrally related..." message.I also tried the

> "ignore ancestry" option via the GUI.
> One, I don't understand why SVN thinks there is even an ancestral relationship
> betweeen the two locations?
> Two, how can I do to get around this error message?
>

From your message I assume that your "branch" install a copy of your trunk, hence not "ancestrally related".

It "thinks" there is a relationship because you are doing a merge. I'm not sure why the "ignore ancestry" doesn't solve the issue though.

Since trunk is empty... why not just delete trunk and copy that branch to trunk?

BOb

[C. Michael Pilato]

On 06/17/2013 11:19 AM, C M wrote:
> Hello,
>
> Code for a new development effort was imported into a developer’s branch.
>
> Now we want merge his changes to trunk (which is currently empty).
>
> I tried the merge from both the command line and the Tortoise GUI and keep
> running into the “…must be ancestrally related…” message.I also tried the
> "ignore ancestry" option via the GUI.
>
> One, I don't understand why SVN thinks there is even an ancestral
> relationship betweeen the two locations?

Subversion doesn't think there is. Rather, it knows there isn't. Hence the
message. The error was introduced to prevent a common mistake folks make
when they misalign their merge sources and targets:

$ svn merge ^/trunk branches
^C^C^Cdangit i meant to type "branches/my-branch"^C^Caaaaagh!

> Two, how can I do to get around this error message?

Well... the --ignore-ancestry option was *supposed* to make that happen for
you. Perhaps there's a bug?

You may need to give a more complete transcript of what you're trying,
including command-line examples and such.

--
C. Michael Pilato <cmpi...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development

[C M]

I think my earlier mistake might have been that I was using the --reintegrate option.
Without it, I make some progress, but still not quite what I am expecting.

Again, given that trunk is empty, why the "C" (tree conflicts)? I would expect all of then to be "A" (additions), no?

The DEV_WC currently only shows the two dirs which SVN correctly recognized as additions.

c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry https://path_to_branch/SCR_BR/

--- Merging r1191 through r1245 into '.':
   C ini
   C txt
   C graphics
   C MMI
   C backups
   C sysctrl
A    sysconfig
A    sysconfig\src
A    sysconfig\src\sysconfig
A    sysconfig\src\sysconfig.c
A    sysconfig\src\sysconfig_init.c
A    sysconfig\src\log
A    sysconfig\src\makefile
A    sysconfig\inc

   C cpu
A    mtl
A    mtl\lib
A    mtl\lib\mtl.lib
A    mtl\src
A    mtl\src\mtl_meter.c
A    mtl\src\mtl
A    mtl\src\makefile
A    mtl\src\mtl.c
A    mtl\inc
A    mtl\inc\mtl_meter.h
   C util_panel
 U   .
Summary of conflicts:
  Tree conflicts: 8

[Bob Archer]

Did you try it without using Dry Run… I have found at times that can cause issues. There’s really no need to use dry run since you can just revert. Just make sure you have no pending changes in your target working copy.

[C. Michael Pilato]

On 06/17/2013 12:39 PM, C M wrote:
> I think my earlier mistake might have been that I was using the
> --reintegrate option.
> Without it, I make some progress, but still not quite what I am expecting.
>
> Again, given that trunk is empty, why the "C" (tree conflicts)? I would
> expect all of then to be "A" (additions), no?
>
> The DEV_WC currently only shows the two dirs which SVN correctly recognized
> as additions.
>
> c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry
> https://path_to_branch/SCR_BR/
>
> --- Merging r1191 through r1245 into '.':

Do these revision numbers (r1191 and r1245) match what you'd expect? What
happens if you do this:

svn diff -r1190:1245 https://path_to_branch/SCR_BR/

Do you see exactly the additions that you would expect to see?

[C M]

Running without the dry-run option doesn't do anything different (it still reports the conflicts). Yes, the diff shows the content I am expecting (at least for the text files).

I ran "svn diff -r1190:1245 --summarize https://path_to_branch/SCR_BR/" and see output like:

M path_to_file

M path_to_file

M path_to_file

Without the "--summarize" option, I see the file content which matches what we are expecting. This is for the text files which SVN identified as being conflicted.

I have several developer branches to merge to trunk. If I can't get the merge to work, is doing a copy from the branch to trunk an option? Will that create further issues downstream? I know no one has a crystal ball, but I have limited experience with SVN and dont know what to expect.

See example below

=========================================
--- txt/pod_block.txt   (revision 1190)
+++ txt/pod_block.txt   (revision 1245)
@@ -1,7 +1,7 @@

[Andrew Reedick]

> From: C M [mailto:cmana...@gmail.com]
> Sent: Monday, June 17, 2013 12:39 PM
> To: C. Michael Pilato
> Cc: Subversion
> Subject: Re: Ancestrally Related Error Message
>

> I think my earlier mistake might have been that I was using the --reintegrate option.
> Without it, I make some progress, but still not quite what I am expecting.
> Again, given that trunk is empty, why the "C" (tree conflicts)? I would expect all of then to be "A" (additions), no?
> The DEV_WC currently only shows the two dirs which SVN correctly recognized as additions.
>
> c:\Temp\DEV_WC>svn merge --dry-run --ignore-ancestry https://path_to_branch/SCR_BR/
>
> --- Merging r1191 through r1245 into '.':
>   C ini
>   C txt
>   C graphics
>   C MMI
>   C backups
>   C sysctrl

>   C cpu
> A    mtl

> Summary of conflicts:
>   Tree conflicts: 8

What kind of tree conflicts are they? 'svn status' should provide more detail. Also, what version of svn are you using? 1.6? 1.7?

Why is trunk empty? Because you deleted trunk after the branch was created? (i.e. create branch, delete trunk/*, merge from branch.)

I get the vague feeling that you have 'incoming add after delete'(?) type messages on the directory conflicts.

[C M]

We are on SVN 1.7.6.

Trunk is empty because this is/was a new development effort. The code was directly imported into the developer's branch.

I ran these two commans in the working copy and get the messages you mentioned. What does that mean?

c:\Temp\DEV_WC>svn merge --dry-run --revision 1190:1233
c:\Temp\DEV_WC>svn status
 M      .
!     C MMI
      >   local delete, incoming edit upon merge
!     C graphics
      >   local delete, incoming edit upon merge
!     C hpu
      >   local delete, incoming edit upon merge
!     C ini
      >   local delete, incoming edit upon merge
!     C misc.backups
      >   local delete, incoming edit upon merge
A  +    mtl
A  +    sysconfig
!     C sysctrl
      >   local delete, incoming edit upon merge
!     C txt
      >   local delete, incoming edit upon merge
!     C util_panel
      >   local delete, incoming edit upon merge

Summary of conflicts:
  Tree conflicts: 8

[Les Mikesell]

On Mon, Jun 17, 2013 at 12:59 PM, C M <cmana...@gmail.com> wrote:
> We are on SVN 1.7.6.
>
> Trunk is empty because this is/was a new development effort. The code was
> directly imported into the developer's branch.
>
> I ran these two commans in the working copy and get the messages you
> mentioned. What does that mean?
>
> c:\Temp\DEV_WC>svn merge --dry-run --revision 1190:1233
> c:\Temp\DEV_WC>svn status
> M .
> ! C MMI
> > local delete, incoming edit upon merge

[...]

And you are merging into a working copy that is a checkout of the
empty trunk? Anyway if the trunk is empty you should get the same
result if you just copy the branch to it.

--
Les Mikesell
lesmi...@gmail.com

[C M]

Well, for what its worth, I was able to complete the "merge" following steps 3 -6 in this article.

http://kirenpillay.blogspot.com/2012/07/svn-merge-tree-conflict-resolution.html

I don't understand why SVN behaved the way it did and prevented the branch to trunk merge as expected..

[Stefan Sperling]

On Mon, Jun 17, 2013 at 04:01:43PM -0500, C M wrote:
> Well, for what its worth, I was able to complete the "merge" following
> steps 3 -6 in this article.
>
> http://kirenpillay.blogspot.com/2012/07/svn-merge-tree-conflict-resolution.html
>
> I don't understand why SVN behaved the way it did and prevented the branch
> to trunk merge as expected..

For some reason, the revision you merged did not carry out
the 'add' action for paths changed by the merge. The merge
performed only an 'edit' (i.e. content modification) action,
and it tried to perform this action on a path which didn't exist.

It is a bit tricky for Subversion to figure out what happened here.
In your particular case, the conflict description 'local delete vs.
incoming edit' is confusing. It is used because:

- Subversion currently has no intelligent way of figuring out what
conflicting changes happened in your repository history, so most
conflict descriptions are more or less educated guesses, and are
*not* strictly based on what actually happened. They are correct
most of the time, but not every time.

- The conflict descriptions were written with the assumption that merges
are performed between ancestrally related branches.

In your case, the latter isn't true. You have a new directory /trunk,
which is empty, and you are trying to merge changes into it. Performing
an 'edit' on something that doesn't exist makes no sense. The thing to
be edited must be created with an 'add' action before it can be edited.
Subversion treats addition and deletions of objects as a first class
operation -- an edit changes an existing object.

When the conflict is flagged, Subversion sees an attempt to edit
an object which does not exist. Assuming the branches are ancestrally
related, and assuming that all changes are merged from the merge source,
the missing object could only be 'deleted' in the target branch's history.
That's why the descriptions says 'local delete'. Does that make sense?

In your case, the conflict description would ideally say something like
'incoming edit for a path which never existed in this branch's history'.
But Subversion is currently not smart enough to describe the conflict in
this way.

In any case, your merge command doesn't seem to be making useful
changes. It looks like you were excluding one or more revisions
which created objects on your branch. If you include those revisions
in your merge to trunk, the merge should succeed.

[Les Mikesell]

On Tue, Jun 18, 2013 at 4:31 AM, Stefan Sperling <st...@elego.de> wrote:

> In your case, the latter isn't true. You have a new directory /trunk,
> which is empty, and you are trying to merge changes into it.

Is there any advantage in merging changes to an empty path as compared
to just copying to it?

--
Les Mikesell
lesmi...@gmail.com

[Stefan Sperling]

On Tue, Jun 18, 2013 at 09:33:25AM -0500, Les Mikesell wrote:
> On Tue, Jun 18, 2013 at 4:31 AM, Stefan Sperling <st...@elego.de> wrote:
>
> > In your case, the latter isn't true. You have a new directory /trunk,
> > which is empty, and you are trying to merge changes into it.
>
> Is there any advantage in merging changes to an empty path as compared
> to just copying to it?

No, the net effect should be the same. But merging the adds and
subsequent modifications should actually work.

[Les Mikesell]

Would it have made a difference in the subversion processing if the
empty trunk had been copied to create the branch before the initial
import? That is, would having a common ancestor as the parent
directory have made the 'adds' merge correctly? It is probably rare
to create a branch that is unrelated to anything else.

--
Les Mikesell
lesmi...@gmail.com

[Stefan Sperling]

On Tue, Jun 18, 2013 at 10:57:28AM -0500, Les Mikesell wrote:
> Would it have made a difference in the subversion processing if the
> empty trunk had been copied to create the branch before the initial
> import? That is, would having a common ancestor as the parent
> directory have made the 'adds' merge correctly? It is probably rare
> to create a branch that is unrelated to anything else.

I don't think it would make a difference. I haven't tried to reproduce
the problem yet, though.

I believe that if the merged revision range includes additions, the merge
should work and add the files -- related ancestry or not. I don't know if
the additions were part of the revision range C M was merging.