The connection of rosinstall to ROS include also the mere existence of 
managed non-scm entries to go into the ROS_PACKAGE_PATH, which would 
make little sense in a multivcs tool, and the detection of a ROS_ROOT 
directory.

And if there were a tool in 2012 called multivcs doing none of the 
above, the ROS community would need a different tool doing all the 
things above still, maybe based on multivcs. So I would like to avoid 
renamig rosinstall now to mulstivcs assuming that what the ROS users 
will have to use in the longer term future will change again. ROS users 
need a tool with ROS connections, so I'd rather use a name with "ros" in 
the REP.

I just need a name to put in the REP, it can be rosws, but that may be a 
bit confusing for now while there is a different process developing 
rosws with features that I put in and then removed again from the REP 
(called "rosinstall shadow/overlay" and "rosinstall remove" at the 
time). But maybe this confusion is bearable.

So shall I go for rosws for now, assuming Brians ideas will be 
implementable as additional commands?

The roswtf API is called "very experimental", but I can still remove the 
check command from the REP, though the checks should in my opinion still 
run before each command to warn users.



On 07/25/2011 11:10 PM, Tully Foote wrote:
>
> Good point, also we've talked about making rosinstall be ROS 
> independent, as it's only actual connection to ROS is the generation 
> of the setup.(ba)sh scripts.  But renaming to something like 
> "multivcs" or "multiscm" would allow us to design the command line 
> syntax w/o needing backwards compatability.
>
> And as rosws etc start being integrated we can let them leverage the 
> new tool but retain ROS integration through that path.
>
> Also for the check/WTF sanity checks, I think it would be better to 
> write a roswtf plugin which would check all those things.  It will 
> help keep a single debugging tool.  And most of that is also ROS 
> specific.
>
> Tully