Welcome to the METAFOR Task Tracker

This Task Tracker allows for the entry of Wiki pages and "tickets" which can be used to track tasks - what needs to be done, who has done what, the status of a task, etc.

To add or edit a ticket, you must first login. Once logged in you will be presented with various menu options. To see more about these options, and how they work, please read the Trac documentation .

some useful links:

•  Gantt Charts of Deliverables and Milestones
•  All PRISM Wiki METAFOR pages have been moved to METAFOR www site
•  METAFOR Launch meeting
•  Project Requirements summary derived from METAFOR Description of Work
•  recent changes

---

How to develop the CIM using Trac & Subversion

(this will become more sophisticated as I learn more - allyn)

useful documentation about SVN lives  here (note this is for version 1.4 which is not the most current version, but the one that we are using)

• All development work should derive from a Trac ticket.
• All development work should be done in a SVN branch.
• All development work should be documented on Wiki pages.
• Branches should use descriptive terms for their names and comments ("foo" is a bad name, "add_model_constraints" is a good name).
• Tickets should provide links (URLs) to related branches and documentation.
• The "CIM Software Manager" should be notified when a branch is ready to be committed to the trunk.
• All UML development is captured within XMI files.

Here is an example:

1.  Sweetums creates a ticket (and assigns it to the appropriate person):  http://metaforclimate.eu/trac/ticket/179
2. He creates a wiki page to document his progress while working on the ticket:  http://metaforclimate.eu/trac/wiki/ticket/179
3. He creates a branch to do the actual work: svn copy http://metaforclimate.eu/svn/CIM/trunk http://metaforclimate.eu/svn/CIM/branches/testBranch -m "a sample branch" --username sweetums
4. He links that documentation and branch to the ticket:  http://metaforclimate.eu/trac/ticket/179#comment:1
5. He checks out that branch to his (local) working copy: svn checkout http://metaforclimate.eu/svn/CIM/branches/testBranch testBranch
6. He makes some changes to his working copy (added software/testFile) and discusses those changes with other members of METAFOR via email, phone calls, forums, whatever.
7. He commits his working copy back to the branch: svn commit -m "added testFile"
8. He makes a final comment in the ticket and reassigned it to the CIM Software Manager:  http://metaforclimate.eu/trac/ticket/179#comment:2 (Note that the reassigning doesn't show up because it was already assigned to allyn. Oh well.)

Here's another example (merging changes):

Working on the same branch:

1.  Statler creates a new branch (as above) and corresponding working copy (as above)
2.  Waldorf creates a working copy based on the same branch (as above)
3. Statler makes some changes to his working copy and commits them to the branch (as above)
4. Waldorf notices a new SVN revision; He dilligently incorporates those changes into his working copy: svn update -r <revision>
5. Waldorf makes some further changes to his working copy and commits them to the branch (as above).
6. Statler ignores those changes and carries on developing his working copy. When he tries to commit his changes SVN checks to see if there is a conflict first. If there isn't then everything proceeds as before. If there is, then Statler has to (with Waldor's help) resolve those conflicts. ( xxdiff works well for this).

Working on different branches:

1.  Link has his own branch as does  Julius; Link wants the changes in his branch merged into Julius' branch.
2. Julius runs: svn merge http://metaforclimate.eu/svn/CIM/branches/linksBranch in his working copy
3. He deals with any conflicts (as above)
4. He commits his newly-changed working copy back to his branch

Here's another example (undoing changes):

1.  Harry does some work and commits his change to a branch
2. He realises he made a mistake and wants to undo the change before other people notice
3. So he merges it with the previous revision: svn merge -c <older revision> http://metaforclimate.eu/svn/CIM/branches/harrysBranch and then commits it to the branch: svn commit -m "backing out changes from revision x" --username harry

One more example (merging things to the trunk):

This is mostly for the CIM Software Manager's use.

1.  Lew checks out the trunk to a working copy (as above) / or makes sure an existing working copy reflected the current state of the trunk (using svn switch / svn update)
2. He works out which set of revisions to merge into the trunk: svn log --verbose --stop-on-copy http://metaforclimate.eu/svn/CIM/branches/testBranch, this will print out a list of each prior commit of testBranch
3. He merges testBranch into the trunk working copy: svn merge -r <start revision>:<end revision> http://metaforclimate.eu/svn/CIM/branches/testBranch (typically, the end revision will be "HEAD" and the start revision will be the last number printed out in the previous step)
4. He check the status and deal with any conflicts (as above)
5. He commits the working copy back to the trunk: svn commit -m "merged testBranch@<current revision> into trunk" --username lew

Once committed to the trunk, tagging / releasing is trivially easy:

1. svn copy http://metaforclimate.eu/svn/CIM/trunk http://metaforclimate.eu/svn/CIM/tags/<my_tag> -m "tagging the CIM for some reason" --username lew (the first argument to copy could just as easily be a branch or a working copy if Lew were tagging for some reason other than a formal release)

---