Home
This wiki is intended for developers of TuLiP, not general users. Users should begin at the TuLiP summary page.
- Main entry point for newcomers (also called the "summary page")
- User's Guide
- Developer's Guide
- API Documentation
- recent snapshot of API Documentation from master branch
The documents pointed to above correspond to the most recent release.
This wiki provides a quick and flexible means for coordinating development efforts. For example, while a feature request and crucial discussion would be made using an "enhancement" issue, a plan for achieving it would be sketched on this wiki.
The text in this section is copied here from an email by Scott to the tulip-control-discuss mailing list on 5 Dec 2015, subject "overhaul merging aftermath". Minor adjustments were made to take advantage of Markdown formatting and links available here in the wiki.
The comments here apply generally for making use of previous repo states, though my focus is on code from old/. All of the code under old/ was deleted in commit 250692133c6ef88d2406f538c97ef0547fa4d90f. Some of old/ (including bits deleted previously) is planned for later inclusion. Given difficulty in tracing the history of such files, which goes back to v0.4a or farther, I recommend the following protocol (I refer to "file" but it applies as well to a "collection of files"):
-
Recreate the file as it was before deletion, in particular with the same path. Do this in a single commit.
-
Rename it or merge with another file, as desired. Unless you are merging, make a single commit in which the file is renamed.
For example, we consider the old code under contrib/tulip_ros. First I need to find the commit in which it was deleted.
$ git log --name-status -- old/contrib/tulip_ros
I then checkout one commit before this one and save the files for later.
$ git checkout 250692133c6ef88d2406f538c97ef0547fa4d90f^
$ cp -ir old/contrib/tulip_ros ..
Some shells will try to interpret ^ before git receives it, so you may
need to use \^ in the above command to escape it. I can now go back
to the head of master and copy the files to where they were previously.
$ git checkout master
$ mkdir -p old/contrib
$ mv ../tulip_ros old/contrib/
Now I can commit it, and then rename it in another commit.
$ git add old/contrib/tulip_ros
$ git commit -m 'Raise the dead: contrib/tulip_ros'
$ git mv old/contrib/tulip_ros contrib
$ git commit -m 'Move tulip_ros from old location'
Finally I can proceed with updating tulip_ros for the new TuLiP (since version 1.0a). Looking at the history of tulip_ros would indicate that it came from old/contrib/tulip_ros, and then something like
$ git log -- old/contrib/tulip_ros
would show that I resurrected it from commit 250692133c6ef88d2406f538c97ef0547fa4d90f, etc.
- Overhaul planning pages -- outlines and notes relevant for the first release of version 1.0.