Hi,
with MOODLE_16_STABLE branch coming soon it would be a perfect moment to review the list of unmerged files trying to merge/tag them as necessary. Sure it will avoid more complexity in the future.
TIA and ciao
Hi Eloy,
I have never merged files before and I see three listed for lesson. Any tips on how to do this? Commands, numbers etc. And I assume we do this to files in HEAD? I found some information in the docs on Working with Branches, but I'm still hesitant to fire off any commands. I'd rather get it right the first time
Thanks,
Mark
I have never merged files before and I see three listed for lesson. Any tips on how to do this? Commands, numbers etc. And I assume we do this to files in HEAD? I found some information in the docs on Working with Branches, but I'm still hesitant to fire off any commands. I'd rather get it right the first time
Thanks,
Mark
Hi Mark,
what we know as HEAD is also called the TRUNK (where all the NEXT major release working HAPPENS). Every time a new new major release is launched a new BRANCH is created for that release. All the bug fixing about that release must be performed over that branch, because minor releases (1.5.1, 1.5.2...) will be created from the code existing in that branch.
But, if you work with the branch and you solve one bug, that bug only has been solved in the branch. Obviously the same change has to be performed to the trunk (or the bug will reappear in next major release!).
Also, every time that one change in one branch is "replicated" in the trunk, it's necessary to add one mark (TAG) in the branch to lets know that we haven't anything pending to "replicate" from the branch to the trunk.
The automatically generated list in my previous post just informs of BRANCH files whose TAG doesn't fit with the last version existing in that branch (i.e. there are some posterior changes in the branch that, potentially haven't been "replicated" in the TRUNK).
And all those files must be examined in the TRUNK (HEAD) to see if the changes in the BRANCH have been "replicated" or no. And there are two possibilities:
1.- Changes have been applied to the trunk. Great! The only thing to do is to move the TAG to allow everybody to know that all the changes in the branch have been "replicated" to the trunk.
2.- Changes haven't been applied to the trunk. No problem! We must "replicate" all those pending changes in the file from the branch to the trunk and then, move the tag like in the point above.
So, going to one real example, we have this (in this exact moment):
- The TRUNK: Called "HEAD" (where all the current 1.6 code reside).
- The BRANCH: Called "MOODLE_15_STABLE" (where all the current 1.5 code reside).
- The TAG: Called "MOODLE_15_MERGED" (that points to the last point of merge performed from the branch to the trunk).
The command to see if one TAG is pointing to the last modification in the branch is:
cvs diff -r TAG -r BRANCH file
if it doesn't shows you anything it means that there aren't differences from the TAG version and the latest changes in the branch. For example if you execute this:
cvs diff -r MOODLE_15_MERGED -r MOODLE_15_STABLE mod/lesson/lib.php
no output will be showed. It means that the mod/lesson/lib.php file is supposed to be merged up to its last change.
But, if you execute the command for any file in the list, for example:
cvs diff -r MOODLE_15_MERGED -r MOODLE_15_STABLE mod/lesson/index.php
You will get something like this:
And this must be a clue to suspect that, perhaps, that change hasn't been applied to the TRUNK, what is, generally, an awful situation. So we must see if the change is present in the trunk. The easier way to see if this changes are present is to execute this command against HEAD (trunk):
cvs update -kk -j TAG -j BRANCH file
whose meaning is "merge all the changes of file from TAG in BRANCH to the version I've locally (HEAD)". I our example, you should be under HEAD in your local CVS and then execute:
cvs update -kk -j MOODLE_15_MERGED -j MOODLE_15_STABLE mod/lesson/index.php
And you get:
It means that all the changes pending in BRANCH (from TAG to the last file version) have been applied to HEAD. Perfect! Then, the only thing to do is to move the TAG to the end of the branch, because we have verified that all the hypothetical pending changes of the file in the BRANCH are now in the TRUNK too. So just, under BRANCH in your local CVS you should execute:
cvs tag -F MOODLE_15_MERGED mod/lesson/index.php
whose meaning is "move the TAG to the last revision of the file in the branch" (remember that we can do it because we have checked that there weren't pending changes to be "replicated-merged" to the trunk).
With this, such file won't be showed in the next list of unmerged files!
Obviously, in the example above, when we have executed the "cvs update", the system has said that no changes were pending so all we have done is to adjust the TAG. Easy. In some other files you will find that such "cvs update" command shows you another type of info, telling that some changes have been performed or that some conflicts exist. In something of this happens, you must edit the file being analysed to solve any conflict (you can easily find conflicts searching for this string: <<<<). But, 99% of the time, CVS will merge changes from BRANCH to TRUNK perfectly. Then you only have to check that everything is ok in TRUNK with one simple:
cvs diff file
and then, if ok (and working! ), just commit such changes to TRUNK with a standard:
cvs commit file
And, finally, in the BRANCH, move the TAG with the command writen some lines above.
And this is all, not sure if this will help you (my English skills are limited). Just re-read now the CVS Docs to see if you understand everything a bit better.
Also, don't forget to execute every action above in the correct place. I've tried to underscore along the text where (TRUNK, BRANCH) every command must be executed: TAG is always moved in BRANCH and update and commit must be executed in TRUNK (exactly as explained in the Docs).
Hope it helps...ciao
what we know as HEAD is also called the TRUNK (where all the NEXT major release working HAPPENS). Every time a new new major release is launched a new BRANCH is created for that release. All the bug fixing about that release must be performed over that branch, because minor releases (1.5.1, 1.5.2...) will be created from the code existing in that branch.
But, if you work with the branch and you solve one bug, that bug only has been solved in the branch. Obviously the same change has to be performed to the trunk (or the bug will reappear in next major release!).
Also, every time that one change in one branch is "replicated" in the trunk, it's necessary to add one mark (TAG) in the branch to lets know that we haven't anything pending to "replicate" from the branch to the trunk.
The automatically generated list in my previous post just informs of BRANCH files whose TAG doesn't fit with the last version existing in that branch (i.e. there are some posterior changes in the branch that, potentially haven't been "replicated" in the TRUNK).
And all those files must be examined in the TRUNK (HEAD) to see if the changes in the BRANCH have been "replicated" or no. And there are two possibilities:
1.- Changes have been applied to the trunk. Great! The only thing to do is to move the TAG to allow everybody to know that all the changes in the branch have been "replicated" to the trunk.
2.- Changes haven't been applied to the trunk. No problem! We must "replicate" all those pending changes in the file from the branch to the trunk and then, move the tag like in the point above.
So, going to one real example, we have this (in this exact moment):
- The TRUNK: Called "HEAD" (where all the current 1.6 code reside).
- The BRANCH: Called "MOODLE_15_STABLE" (where all the current 1.5 code reside).
- The TAG: Called "MOODLE_15_MERGED" (that points to the last point of merge performed from the branch to the trunk).
The command to see if one TAG is pointing to the last modification in the branch is:
cvs diff -r TAG -r BRANCH file
if it doesn't shows you anything it means that there aren't differences from the TAG version and the latest changes in the branch. For example if you execute this:
cvs diff -r MOODLE_15_MERGED -r MOODLE_15_STABLE mod/lesson/lib.php
no output will be showed. It means that the mod/lesson/lib.php file is supposed to be merged up to its last change.
But, if you execute the command for any file in the list, for example:
cvs diff -r MOODLE_15_MERGED -r MOODLE_15_STABLE mod/lesson/index.php
You will get something like this:
< <?PHP // $Id: index.php,v 1.10.2.1 2005/06/07 20:48:41 michaelpenne Exp $It means that there are some changes between the TAG and the latest version in the branch.
---
> <?PHP // $Id: index.php,v 1.10.2.2 2006/02/24 21:27:51 michaelpenne Exp $
28a29,30
> } else {
> $navigation = '';
97c99
< $table->data[] = array ($link, $grade_value, $due);
---
> $table->data[] = array ($link, $lesson->grade, $due);
And this must be a clue to suspect that, perhaps, that change hasn't been applied to the TRUNK, what is, generally, an awful situation. So we must see if the change is present in the trunk. The easier way to see if this changes are present is to execute this command against HEAD (trunk):
cvs update -kk -j TAG -j BRANCH file
whose meaning is "merge all the changes of file from TAG in BRANCH to the version I've locally (HEAD)". I our example, you should be under HEAD in your local CVS and then execute:
cvs update -kk -j MOODLE_15_MERGED -j MOODLE_15_STABLE mod/lesson/index.php
And you get:
Merging differences between 1.10.2.1 and 1.10.2.2 into index.php
mod/lesson/index.php already contains the differences between 1.10.2.1 and 1.10.2.2
It means that all the changes pending in BRANCH (from TAG to the last file version) have been applied to HEAD. Perfect! Then, the only thing to do is to move the TAG to the end of the branch, because we have verified that all the hypothetical pending changes of the file in the BRANCH are now in the TRUNK too. So just, under BRANCH in your local CVS you should execute:
cvs tag -F MOODLE_15_MERGED mod/lesson/index.php
whose meaning is "move the TAG to the last revision of the file in the branch" (remember that we can do it because we have checked that there weren't pending changes to be "replicated-merged" to the trunk).
With this, such file won't be showed in the next list of unmerged files!
Obviously, in the example above, when we have executed the "cvs update", the system has said that no changes were pending so all we have done is to adjust the TAG. Easy. In some other files you will find that such "cvs update" command shows you another type of info, telling that some changes have been performed or that some conflicts exist. In something of this happens, you must edit the file being analysed to solve any conflict (you can easily find conflicts searching for this string: <<<<). But, 99% of the time, CVS will merge changes from BRANCH to TRUNK perfectly. Then you only have to check that everything is ok in TRUNK with one simple:
cvs diff file
and then, if ok (and working! ), just commit such changes to TRUNK with a standard:
cvs commit file
And, finally, in the BRANCH, move the TAG with the command writen some lines above.
And this is all, not sure if this will help you (my English skills are limited). Just re-read now the CVS Docs to see if you understand everything a bit better.
Also, don't forget to execute every action above in the correct place. I've tried to underscore along the text where (TRUNK, BRANCH) every command must be executed: TAG is always moved in BRANCH and update and commit must be executed in TRUNK (exactly as explained in the Docs).
Hope it helps...ciao
Hi Eloy,
Thanks for your very detailed answer It makes a lot more sense now. I'll try playing around with the above instructions this weekend.
Cheers and thanks,
Mark
Thanks for your very detailed answer It makes a lot more sense now. I'll try playing around with the above instructions this weekend.
Cheers and thanks,
Mark
Hi Eloy,
I had forgotten about this problem and now I'm trying to figure it all out. I followed your steps for mod/lesson/index.php and I'm not sure if it worked. Is there a way to test this? I don't want to move onto other files without making sure I'm doing this correctly.
Cheers,
Mark
I had forgotten about this problem and now I'm trying to figure it all out. I followed your steps for mod/lesson/index.php and I'm not sure if it worked. Is there a way to test this? I don't want to move onto other files without making sure I'm doing this correctly.
Cheers,
Mark
Hi Mark,
I suppose that you have executed the command (in HEAD!):
cvs update -kk -j MOODLE_15_MERGED -j MOODLE_15_STABLE mod/lesson/index.php
with this, all the pending changes in MOODLE_15_STABLE should be now present in HEAD (in your working directory, not in the CVS server!). Then, all you have to do is (in HEAD):
- Before commit changes in HEAD, execute one cvs diff to see that changes are really there.
- Test that code is working.
Then you can, safely, commit such changes in HEAD and move the TAG in MOODLE_15_STABLE as explained in my previous post.
Ciao
I suppose that you have executed the command (in HEAD!):
cvs update -kk -j MOODLE_15_MERGED -j MOODLE_15_STABLE mod/lesson/index.php
with this, all the pending changes in MOODLE_15_STABLE should be now present in HEAD (in your working directory, not in the CVS server!). Then, all you have to do is (in HEAD):
- Before commit changes in HEAD, execute one cvs diff to see that changes are really there.
- Test that code is working.
Then you can, safely, commit such changes in HEAD and move the TAG in MOODLE_15_STABLE as explained in my previous post.
Ciao