Hi all, As this conversation has languished a bit I wanted to revive it. I spent some time in front of a whiteboard and talked to people as they went past as I was sketching how this might work. Thanks to Thibault's patches if you'd like to try out rosinstall commands --status and --diff the latest version of rosinstall has them implemented for testing but not documented until this process is done. In my brainstorming, I started with the premise that this would be a tool which would do configuration management and would leverage rosinstall underneath. And to be able to help you the most at initialization it will need to know what distro it is working against. Similarly as we've talked about before there seems to be a consensus that scm type syntax is preferred, so like svn, hg, and git it will look at the current tree and traverse upwards so as not to need to take a path in every call. A global --path option can be used to allow execution of any command from an arbitrary CURDIR Also there are three common states for a package which the user cares about. The user will want the development version of a package, the released version of a package, or they don't care, which I'll call undeclared. Starting with the simplest, a development stack will simply be checked out from the development branch for the distro. Then all the dependencies of the union of development stacks and declared "released" stacks is computed. Any package dependent on the development stack(s) is installed from source, while all other stacks are installed from binary if possible. Undeclared is the default state, and the stack will be installed if another stack depends on it. These states are mutually exclusive, and we could provide commands to switch between them for each stack. And for flexibility, we could allow overriding the local-name and version. local-name would default to the stack name in the workspace. And the version would default to the value defined in the rosdistro file. There are 6 transitions between the 3 states possible, after considering different commands for each leg, a more declarative statement of the end state will make things simpler. Below are the 6 transitions and my proposed commands undeclared => development command develop undeclared => released command released released => undeclared command undeclare released => development command develop development => undeclared command undeclare development => released command released For advanced users who have a very special configuration a .rosinstall file will be supported, and appended to all calls to rosinstall. (U16) The configuration status can be stored in a .rosws file. {{{ distro: electric development: - geometry: released: [rviz] }}} = Commands = rosws init DISTRO=DEFAULT_DISTRO PATH='.' * Initialize the directory PATH as a ros workspace, with the DEFAULT_DISTRO, electric as default. rosws develop STACKNAME [--version branchname] [--local-name alt_local_path] * Add STACKNAME to the list of stacks to install the development branch rosws undeclare STACKNAME * remove the stack from either development list or released list rosws released STACKNAME * set the stack to be the released version rosws snapshot * create a rosinstall file which is a snapshot of all the source based installations, assumes binary installations are present as required * --full an option to export a rosinstall with a full source based installation for true snapshotting. * --tarball an option to generate a completely self standing tarball of all the stacks source ready to build. * -O output_filename rosws diff * output the diffs from each source checkout rosws status * output the status of each source checkout rosws info * display the current state of the configuration in a nice human readable format = Syncronization = rosws executes on every command. Multiple arguments can be passed on one line and execution will be deferred until the end state and options except for global ones are left associative. rosws init electric develop geometry --version not_optimized released visualization Would checkout geometry version not_optimized and everything up through visualization from source at the end. = Use case analysis = Sample usage: Stack developer who wants to develop stack geometry in ROS electric and test up through rviz cd /tmp/test rosws init electric rosws develop geometry rosws released rviz . setup.bash DO SOMETHING IN GEOMETRY rosmake rviz -t Sample usage: Duplicate another workspace U1, U2 cd /tmp/test rosws init --config /tmp/other_ws/.rosws Follow above with below for U3 rosws develop geometry Follow avove with belwo for U4 rosws released rviz U5 rosws update U6: changing the version of a stack rosws develop geometry OR rosws released geometry OR rosws undeclare geometry U7: rosws released rviz U8: NA not order dependent. U9: rosws purge U10: NA U11: rosws snapshop -O config.filename U12: rosws init --config-file=filename U13: rosws develop ros U14: duplicate U1 U15: rosws develop geometry --local-name my/custom/path U16: Make changes to .rosinstall in the root directory U17 rosws diff U18 rowsw status = My Comments = I feel that the snapshot function is the least well defined. I can think of many different use cases with different requirements. I'm a little worried about trying to do to much and doing it inadaquately. Most of the features could be covered by copying the .rosws and .rosinstall together. All the choices of names and verbiage should be reviewed. In particular the "released' and "undeclare" keywords seem like they could be reforumlated to make more sense. Thoughts? Tully On Wed, Aug 10, 2011 at 9:01 PM, Ken Conley wrote: > The new REP 110 document has been resynced to: > > http://www.ros.org/reps/rep-0110.html > >  - Ken > > On Wed, Aug 10, 2011 at 2:22 PM, Thibault Kruse wrote: >> Sorry for me being slow on REP 110. >> >> I updated the REP document still on >> http://code.in.tum.de/indefero/index.php//p/rosinstall2/source/tree/master/rosinstall-REP.txt >> >> For now I suggest in the REP to use rosws as name. I cut down the >> diverse commands init, update, add, remove, ... to just install. Which >> makes the REP look a bit silly, as I list 18 use cases most of which now >> are served by "manually update your .rosinstall, then run 'rosws install .'" >> >> To reduce the wait time for the features I might, if Tully agrees, >> provide status, diff, info as -- options in rosinstall as it is, then >> the REP would really just change the syntax, not introduce features. >> >> regards, >>   Thibault >> _______________________________________________ >> ros-users mailing list >> ros-users@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-users >> > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > -- Tully Foote Systems Engineer Willow Garage, Inc. tfoote@willowgarage.com (650) 475-2827