The Tiki Version lifecycle uses different branches (ex: trunk, 4x, proposals/4x) which have different levels of maturity and stability. The disadvantage is that you often need to take a change made on one branch, and reproduce it on another branch.
This page explains how to do this, either with the SVN command line, or with Eclipse.
Terminology
In the rest of this page, we will use the following terminology
- Origin branch: The branch which has the change you want to reproduce on another branch.
- Origin project: The Eclipse project which you use to work on the Origin branch(see above definition).
- Destination branch: The branch on which you want to reproduce the change.
- Destination project: The Eclipse project which you use to work on the Destination branch(see above definition).
With SVN command line
Please help by writing instructions for this here.
Here is an example: Commit to a proposals branch
With Eclipse
Suppose you made and committed a change on trunk, and you want to reproduce it in proposals/4x, so that the Quality team can look at it and decide if it should be backported to the Tiki4 release.
Here's how you would do it.
Make sure your change is committed to the Origin Branch
If a change only exists on your local working copy of a branch, you cannot reproduce that change on another branch. So, the first step it to commit your change to the SVN repository.
Find the revision number of your change
- Go to the Eclipse Resources perspective,
- Right click on the Origin Project (tiki-trunk in this case).
- Team > Show history
This will show a recent history of changes made to the project.
Locate the revision number of the change you want to reproduce in the Destination Branch (24025 in this case).
Commit any unccommited changes that may reside in your Destination Project
If you have some changes in your Destination Project which need to be commited, do that first, before you attempt to reproduce a change from the Origin Branch.
Refresh the Destination Project
If you Destination project is out of sync with what's on the file system (ex: if Tiki changed the cache files), the Merge dialog may fail. So it's a good idea to always refresh that project first.
- In the Eclipse Resource perspective, right click on the Destination Project.
- Refresh
Invoke the Merge dialog
- In the Eclipse Resources perspective, right click on the Destination project (proposals/4x in this case).
- Team > Merge
- In the Merge dialog
- Click on the Select button, then navigate to the Origin branch (trunk in this case)
- Click on OK button
- In the To: (end URL and revision of range to merge) section:
- Make sure the Use "From:" url box is checked.
- Make sure the Merge from HEAD revision is left unchecked
- In the Revision field, enter the revision for the change you want to reproduce. In this case, that is 24025.
- Click on the Merge button.
Inspect the changes made on the Destination Project
- In the Eclipse Resource perspective, right click on the Destination Project (prop-tiki4 in this case).
- Compare With > Base Revision
- In the Structure compare section, double click on each file in turn, and make sure that the diff is a change that you intended.
- In some cases, you may notice that your local copy has several versions of a same file, with suffixes .merge-left.rN, .merge-right.rN and .working (where N represents the revision number of the change you want to reproduce).
- This indicates that there was a conflict between the two branches for that file, and that you need to manually resolve it.
- The easiest thing is to edit the actual file (multilinguallib.php in this screen shot). In each section where some diffs were encountered, you will see two versions, enclosed in the following tags
<<<<<<< .working Code as it used to be in the Destination Branch. ======= Code as it appears in the Origin Branch, after the change that you want to reproduce on the Destination Branch. >>>>>>> .merge-right.rN
- Simply figure out what this part of the code should be in the Destination Branch, and remove the tags.