info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Merging from one branch to another


From: Chris Sherman
Subject: Merging from one branch to another
Date: Fri, 20 Apr 2001 02:48:58 -0400
User-agent: Mutt/1.2.5i

Mind if I ask a stupid question?  I'm getting a very
weird merge error, and I just want to know if what I'm
doing is even allowed/legal/etc...  (The docs say it
should be ok--but I'm just making sure).

I have a setup where I have a 2 branches and a trunk.
Both branches come off the Trunk at different points.

================Trunk=========
    \   \
     \   \______Branch 1______
      \_________Branch 2______


Most changes are committed into Branch 2, with only a few
committed on Branch 1.  Every week, all the changes on
Branch 2 are merged into Branch 1, and then Branch 1 is
merged into the Trunk.

Branch 2 represents an older version of the code, which is still
being maintained.  Branch 1 represents new development (but also
gets all development code committed to branch 2, but not
vice-versa).  The Trunk represents the latest, weekly, tested,
working code.  Nothing gets pushed to the trunk until its ready,
but branches are a different matter (they're for developement).

Does all this sound ok so far?  I mean (stupid question
time), CVS can do this, right?

I follow the CVS manual where it says to keep a floating
tag that represents the spot on the branch where I
last merged (I have two of these, one for each branch).  So the
merge commands to merge changes from Branch 2 upto Branch 1 look
like:

# create a merge pen
mkdir merge_pen
cd merge_pen
cvs checkout -r Branch_1 Project

# merge in the changes on Branch_2
cvs update -j Branch_2_last_merge_w_Branch_1 -j Branch_2

# and if I don't get conflicts, which to Branch_2 and mark
cvs update -r Branch_2
cvs tag -F Branch_2_last_merge_w_Branch_1 

But the problem I'm getting is that during the cvs update -j -j,
I'm getting a conflict in a file that was only changed on Branch 2
and never directly touched on Branch 1.  That is, a user touched
file 'a', then we did a merge from Branch 2 to Branch 1, then
file 'a' was modified again, and now we get conflicts trying to
merge to Branch 1 again.  (Does this make sense?)

Here is the code before the merge (it appears this way on
Branch 1, Branch 2, and the Trunk):

   # see if there is maintenance on the media
   if ($gbl->{TOC}->get_toc_header("maint") eq "false") { return; }

   my $response = &_prompt_for_maint($gbl);

   if ($response eq "signal=GOBACK") {
     return "signal=GOBACK";
   }

   # They chose no maint
   elsif ($response == FALSE) {

     if ($install_type eq "quick") {
       &_load_no_maint($gbl);
     }
     # Give them a chance to choose maint if any Asyncs were selected
     elsif ($install_type eq "custom") {
       if (&_custom_no_maint($gbl) eq "signal=GOBACK") {
         return "signal=GOBACK";
       }
     }
   }

   # Install the maint
   else {
      &_update_for_maint($gbl);
   }

Here is the new code committed to Branch 2:

   # see if there is maintenance on the media
   if ($gbl->{TOC}->get_toc_header("maint") eq "false") { return; }

   # Install the hotfixes
   &_update_for_maint($gbl);


Here is the conflict when trying to merge Branch 2 onto Branch 1:

   # see if there is maintenance on the media
   if ($gbl->{TOC}->get_toc_header("maint") eq "false") { return; }

   my $response = &_prompt_for_maint($gbl);

   if ($response eq "signal=GOBACK") {
     return "signal=GOBACK";
   }

<<<<<<< maintinstall.pm
   # They chose no maint
   elsif ($response == FALSE) {

     if ($install_type eq "quick") {
       &_load_no_maint($gbl);
     }
     # Give them a chance to choose maint if any Asyncs were selected
     elsif ($install_type eq "custom") {
       if (&_custom_no_maint($gbl) eq "signal=GOBACK") {
         return "signal=GOBACK";
       }
     }
   }

   # Install the maint
   else {
      &_update_for_maint($gbl);
   }
=======
   # Install the hotfixes
   &_update_for_maint($gbl);
>>>>>>> 1.9.4.1


Isn't that just completely weird???  What went wrong?  Lines 4-8
(in the last section) aren't even marked in the conflict, even
though they went away.  And since there were never any commits
to this file in Branch 1, where did the conflict come from in the
first place???  I'm so confused...

Side note:  Upgrading to cvs 11 is tricky...  We've made some
mods to cvs (unrelated to branching, just some minor additions to
the client/server protocol that carries additional info on each
file), that would require some work to get moved up into 11.  But
I'm willing to entertain that this is a bug in 10.7 if someone
has seen something like this before.

But mostly, I'm after whether I'm doing the right thing
in the way I have this set up...  That's the big question.

Thanx for any help!!!  (And sorry about the long post).

-- 
Chris Sherman
address@hidden
JAPH / UNIX RE / STO



reply via email to

[Prev in Thread] Current Thread [Next in Thread]