Ancestry for dummies

["Brown, Carlton" <Ca...@BellSouth.com>]

I am trying to figure out how merging treats ancestry, and in what
scenarios it would be important to use --ignore-ancestry (or not).

I spent a few hours setting up tests of varying complexity where I
branched, made some parallel changes, and then tried to merge them back
together, generally following this method.
1 Create dir R1.0/trunk
2 Copy R1.0/trunk/FeatureA/trunk
3 Make parallel changes to different parts of a file in R1.0 and
FeatureA
4 Baseline R2.0/trunk by doing svn copy of R1.0/trunk to R2.0/trunk
(ancestry retained)
5 Merge changes from FeatureA/trunk into R2.0/trunk

I noted the results, then repeated the tests with one change:  Instead
of re-baselining with "svn copy", I performed an export of R1.0 and
imported it to R2.0.  So they were still identical, yet all the ancestry
had been discarded in R2.0

To my surprise, the results were identical in both case.  I expected
that without having an ancestry for context, the merge tool would make a
bunch of inaccurate edits.   But it performed the same way in both
cases, automatically merging the simple cases, throwing conflicts for
the complex ones.

So how does ancestry relate to merging, and what is a scenario where
using or ignoring ancestry would be really important?

Thanks,
Carlton

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624

Re: Ancestry for dummies

[deckrider <de...@gmail.com>]

On 12/4/06, Bob Hiestand <bo...@gmail.com> wrote:
> I don't think the ancestry matters in the merge target, only in the
> sources.

I'm using svn 1.3.2.  We have a production branch that occasionally
gets small fixes and then these fixes are merged into the trunk where
our next release is being worked.

In one case, where we renamed one of the files on the trunk, we have
this message come in when it needs changes from the production branch:

   Skipped missing target: path/to/renamed/file

It would be great if ancestry would be noticed here so that it would
know that we had earlier done 'svn mv' on that file in the trunk.

In my mind, it is this aspect of ancestry that would matter (at least
to me) in the merge target.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Ancestry for dummies

["Brown, Carlton" <Ca...@BellSouth.com>]

So let me boil down the question... in all my testing, I see no
difference in the outcome of merging regardless of whether
--ignore-ancestry is used.  The only difference is whether a certain
merge was registered as a modify versus an add, but the content was
exactly the same.  

So why does the merge command even have --ignore-ancestry?  In what case
would this ever make a meaningful difference?  Why isn't
--ignore-ancestry the default?

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Ancestry for dummies

[Bob Hiestand <bo...@gmail.com>]

On 12/4/06, Brown, Carlton <Ca...@bellsouth.com> wrote:
> 5 Merge changes from FeatureA/trunk into R2.0/trunk
>
> I noted the results, then repeated the tests with one change:  Instead of
> re-baselining with "svn copy", I performed an export of R1.0 and imported it
> to R2.0.  So they were still identical, yet all the ancestry had been
> discarded in R2.0

I don't think the ancestry matters in the merge target, only in the
sources.  You are merging INTO R2.0, so the relative diff calculated
between FeatureA and R1.0 (I assume that's how you're doing it) works
fine (ie, they have shared ancestry in both merges you perform) and
doesn't care whether R2.0 shares ancestry.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org