info-cvs
[Top][All Lists]
Advanced

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

Problem with multiple merges from trunk to tree (and much more. :-)


From: Garvin Hicking
Subject: Problem with multiple merges from trunk to tree (and much more. :-)
Date: 14 Jul 2001 22:07:00 +0200

Hi!

(Warning: Detailed Vehicle Ahead - skip all ">" and "|"-lines or proceed  
to the last 10 lines of my posting, if this is too much overhead for you.  
And, this is a so-to-say addon for ony of my previous posting 'how to  
structure my project?' :-)

  I'm having difficulties tagging files and merging between a trunk and a  
branch. I will explain it in a more detailed example:

  I have a new project called "project" containting a file "test.php".  
This is the only file after the initial import. I now check out my working  
copy:

        > cvs checkout project

  I want to have the trunk as the main development line (I was told to do  
so...) and have a seperate branch containing the most recent final  
version. The project will often contain files in the development tree  
which are modified during a long time and also some files which have to be  
"hotfixed" very quickly. The whole project is a webpage only, so no real  
version numbers have to be associated with the program. Also, it will  
never have to happen that I have to fix a final version released 2 weeks  
ago - only the current final version will have to get updated. Back to my  
layout, I want to branch a final-tree via

        > cvs tag milestone_1 project
        | cvs tag: Tagging project
        | T project/test.php
        > cvs rtag -b -r milestone_1 final project
        | cvs rtag: Tagging project

  Now I can create local working directory "dev" and "final". Now I will  
place the files inside the new dirs:

        [/dev]
        > cvs checkout project
        | cvs checkout: Updating project
        | U project/test.php

        [/final]
        > cvs checkout -r final project
        | cvs checkout: Updating project
        | U project/test.php

  Now here's a typical development cycle, happening quite often a day:

  1. I edit the files, which won't be published in the final version until  
they are "out of beta" - say, I edit the file "test.php". From time to  
time, I will commit my changes to this file to the development trunk, so  
that other developers can take part in that.
  2. I get the urgent message, that a new file has to be added, or an  
existing file (none so far) has to be updated in the final version (as  
well as the ongoing development version).

  So I will usually add the file in my working directory:

        [/dev]
        > touch newfile.php
        > cvs add newfile.php
        | cvs add: scheduling file 'newfile.php' for addition
        | cvs add: use 'cvs commit' to add this file permanently
        > cvs commit -m "initial revision" newfile.php
        | RCS file: /Repository/project/newfile.php,v
        | done
        | Checking in newfile.php;
        | /Repository/project/newfile.php,v  <--  newfile.php
        | initial revision: 1.1
        | done

  After that, I want the new file "newfile.php" as well in the final  
version. I then place a new milestone-tag on my working directory, but  
only for the new file(s) - because I don't want other files from my  
working directory to be included in final:

        [/dev]
        > cvs tag milestone_2 newfile.php
        | T newfile.php

  I then include my milestone_2 changes into the final version:

        [/final]
        > cvs -q update -j milestone_2 project
        | U project/newfile.php
        > cvs commit -m "merged from milestone_2" project
        | cvs commit: Examining project
        | Checking in project/newfile.php;
        | /Repository/project/newfile.php,v  <--  newfile.php
        | new revision: 1.1.2.1; previous revision: 1.1
        | done

  Now the final version in my working directory is correctly updated. I  
can now go to my production machine and make a

        [/production]
        > cvs export -r final project
        | cvs export: Updating project
        | U project/newfile.php
        | U project/test.php

  This works well. But now, I get the message, that newfile.php has  
errors. I switch to my development-tree, edit the file and correct the  
bugs. After that, I will do:

        [/dev]
        > cvs commit -m "fixed bug" newfile.php
        | Checking in newfile.php;
        | /Repository/project/newfile.php,v  <--  newfile.php
        | new revision: 1.2; previous revision: 1.1
        | done
        > cvs tag milestone_3 newfile.php
        | T newfile.php

        [/final]
        > cvs -q update -j milestone_3 project
        | RCS file: /Repository/project/newfile.php,v
        | retrieving revision 1.1
        | retrieving revision 1.2
        | Merging differences between 1.1 and 1.2 into newfile.php
        > cvs commit -m "merged from milestone_3" project
        | cvs commit: Examining project
        | Checking in project/newfile.php;
        | /Repository/project/newfile.php,v  <--  newfile.php
        | new revision: 1.1.2.2; previous revision: 1.1.2.1
        | done
*

        [/production]
        > cvs export -r final project
        | cvs export: Updating project
        | cvs export: move away project/newfile.php; it is in the way
        | C project/newfile.php
        | U project/test.php

  So the first conflict shows up here - the version with the fixed bug is  
not exported. The existing directory already contains the newfile.php,  
because it was added in milestone_3. But now, CVS thinks it was just  
added, and wonders why the file already exists. Where did I miss the  
point? Was I to add some sticky tag or so at the step, where I have placed  
a "*"? (after the commit from 'merged milestone_3').

  Anyway, if I would continue my work like, let's say, this file still has  
bugs. I will again switch to my development-tree, edit the file and then:

        [/dev]
        > cvs commit -m "fixed bugs (again - *sigh*)" newfile.php
        | Checking in newfile.php;
        | /Repository/project/newfile.php,v  <--  newfile.php
        | new revision: 1.3; previous revision: 1.2
        | done
        > cvs tag milestone_4 newfile.php
        | T newfile.php

        [/final]
        > cvs -q update -j milestone_4 project
        | RCS file: /Repository/project/newfile.php,v
        | retrieving revision 1.1
        | retrieving revision 1.3
        | Merging differences between 1.1 and 1.3 into newfile.php
        | rcsmerge: warning: conflicts during merge

  So, now a more serious (or as serious as the error before? ;-) error  
kicks in. The newfile.php isn't recognized as the version contained in  
milestone_3, but is treated like the milestone_2 version - the newfile.php  
looks like that:

        | <<<<<<< newfile.php
        | fixed a bug!
        | =======
        | fixed another bug!
        | fixed a bug!
        | >>>>>>> 1.3
        | contains a bug

  (Explanation: The initial version (on milestone_2) only contained the  
line "contains a bug". The milestone_3 version added the line "fixed a  
bug". The milestone_4 version added the line "fixed another bug".)

  Of course, I expected that CVS would simply merge the differences  
between the first bugfix and the second. I think, the problem is that I  
only tag single files as new milestones, not a complete directory. But I  
do not want to build a complete working directory, then merge in the  
differences, then tag the whole directory and thereafter update the final  
with the new tag.

  How would you get along with my requirements[1]?

Thanks for your help, and your time for reading this,
Garvin.

[1] Requirements:
 * Maintain a development line, and a final line
 * Easy to export the production version of the project via a never-
   changing tag/branch
 * Easy to modify files in the development line without integrating them
   into the final line
 * Easy to modify files from the final line, which will immediately get
   modified in the development version (or vice versa)
 * No need to create working directory apart from beta/, final/ and
   production/
 * Easy tagging, if possible (I don't want to tag every single file in the
   project with specific revisions only because of one file getting
   updated)



reply via email to

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