Review unmerged files please...

Review unmerged files please...

by Eloy Lafuente (stronk7) -
Number of replies: 5
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
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 smile
Average of ratings: -
In reply to Eloy Lafuente (stronk7)

Re: Review unmerged files please...

by Mark Nielsen -
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 wink

Thanks,
Mark
In reply to Mark Nielsen

Re: Review unmerged files please...

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
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:
< &lt?PHP // $Id: index.php,v 1.10.2.1 2005/06/07 20:48:41 michaelpenne Exp $
---
> &lt?PHP // $Id: index.php,v 1.10.2.2 2006/02/24 21:27:51 michaelpenne Exp $
28a29,30
> } else {
> $navigation = '';
97c99
&lt $table->data[] = array ($link, $grade_value, $due);
---
> $table->data[] = array ($link, $lesson->grade, $due);
It means that there are some changes between the TAG and the latest version in the branch.

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! wink ), 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 smile



Average of ratings: Useful (2)
In reply to Eloy Lafuente (stronk7)

Re: Review unmerged files please...

by Mark Nielsen -
Hi Eloy,

Thanks for your very detailed answer smile  It makes a lot more sense now.  I'll try playing around with the above instructions this weekend.

Cheers and thanks,
Mark
In reply to Eloy Lafuente (stronk7)

Re: Review unmerged files please...

by Mark Nielsen -
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
In reply to Mark Nielsen

Re: Review unmerged files please...

by Eloy Lafuente (stronk7) -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
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. wink

Then you can, safely, commit such changes in HEAD and move the TAG in MOODLE_15_STABLE as explained in my previous post.

Ciao smile