Derek Robert Price [EMAIL PROTECTED] wrote on 11/06/2003 04:37:03 PM:
I see it now, and I thought that the conflicts you now say don't occur
were the ones you objected to in the first place.
Not at all. The conflicts that troubled me were happening because I was
double-merging (when bringing B
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood wrote:
|Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 12:43:14 PM:
|
|Greatest Common Ancestor, or GCA, is a term that refers to the RCS
|revision structure and always means the more recent revision two
|revisions have in common,
Derek Robert Price [EMAIL PROTECTED] wrote on 11/06/2003 08:57:22 AM:
The way to avoid only processing this for whole branch merges is to
track individual commits as change sets. For example, store that the
sum of changesets for file1 1.2 - 1.2.4.7 have been merged into the
trunk. Then
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood wrote:
|Derek Robert Price [EMAIL PROTECTED] wrote on 11/06/2003 08:57:22 AM:
|
|The way to avoid only processing this for whole branch merges is to
|track individual commits as change sets. For example, store that the
|sum of changesets
Is it just me, or is this getting way too complex to be usable except by
CVS experts?
I thought I was comfortable with the issues surrounding branches and
merges, even though we are not using branches yet here. But I don't
understand half of what you folks are saying.
Worse: in my
Please correct me if I'm wrong. I _think_ this is the greatest common
ancestor problem. And finding one is actually something CVS does for you
- on the first mege (with a single -j). Which is usually OK in cases where
a branch immediately dies (i.e. becomes dormant) afterwards.
The problem is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood wrote:
|Please correct me if I'm wrong. I _think_ this is the greatest common
|ancestor problem. And finding one is actually something CVS does for you
|- on the first mege (with a single -j). Which is usually OK in cases where
|a branch
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM:
No. The GCA has not changed and CVS determines it correctly. You
simply no longer wish to merge from the GCA forward because some of
those changes were already merged to your destination (from another
branch and at your
On Wed, Nov 05, 2003 at 08:55:38AM +, Andy Jones wrote:
Is it just me, or is this getting way too complex to be usable except by
CVS experts?
I thought I was comfortable with the issues surrounding branches and
merges, even though we are not using branches yet here. But I don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood [EMAIL PROTECTED] writes:
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM:
No. The GCA has not changed and CVS determines it correctly. You
simply no longer wish to merge from the GCA forward because some of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Wood wrote:
|Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM:
|
|No. The GCA has not changed and CVS determines it correctly. You
|simply no longer wish to merge from the GCA forward because some of
|those changes were
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Derek Robert Price wrote:
| Greatest Common Ancestor, or GCA, is a term that refers to the RCS
| revision structure and always means the *more* recent revision two
| revisions have in common, often a branch point, but in the case of a
| branch of a
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 12:43:14 PM:
Greatest Common Ancestor, or GCA, is a term that refers to the RCS
revision structure and always means the more recent revision two
revisions have in common, often a branch point, but in the case of a
branch of a branch and
Let me try to put it another way.
I have a parent branch, and it has two child branches. If I want one child
to merge to the parent, and then to the other child, how does that other
child later merge to the parent as well?
Is it (on the parent): update -j first_child_merge_point -j second
Sorry for the ascii graphic in advance . . .
If you have (* indicates merge point):
branchA and branchB originated from trunk at point 1.
branchA merged to trunk at point 2 on branchA and 2' on trunk.
branchA then merged to branchB at point 3 on branchA and 3' on branchB.
Now, we want to merge
I would say your ascii graphic is admirable!
What you are saying matches what I'm seeing in tests, and I think I get it
now.
I believe my problem has been a silly confusion with the way update -j -j
works.
I understand a merge between 1 and 4 (and for that matter, a reverse-merge
between 4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If branch A and branch B in your example don't branch form the same
point on the trunk, a merge from point 2 to point 4 into the trunk might
still not do what you want. If branch B branched first, then 2-4 may
back out changes made to the trunk
On Tue, Nov 04, 2003 at 01:27:09PM -0500, Derek Robert Price wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If branch A and branch B in your example don't branch form the same
point on the trunk, a merge from point 2 to point 4 into the trunk might
still not do what you want. If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Wellnitz wrote:
|On Tue, Nov 04, 2003 at 01:27:09PM -0500, Derek Robert Price wrote:
|
|-BEGIN PGP SIGNED MESSAGE-
|Hash: SHA1
|
|If branch A and branch B in your example don't branch form the same
|point on the trunk, a merge from point
I am not sure about something.
|If branch A and branch B in your example don't branch form the same
|point on the trunk, a merge from point 2 to point 4 into the trunk
might
|still not do what you want. If branch B branched first, then 2-4 may
|back out changes made to the trunk between the
20 matches
Mail list logo
