Hello Thibault et al., I appreciate your working on rosinstall. It isn't that easy to understand. And I really hate running it for an update because I get absolutely no idea what had been changed and therefore will help or disturb my development. If that's what your --diff is to be meant for, that would be great! (Let me know if I missed the view-detailed-changes-before-updating feature somewhere.) Best Regards, Felix 2011/7/20 Thibault Kruse : > Hi, > > ok, in our latest git version, I removed shadow/overlay. > > I removed add + apply, and replaced them with "merge", which does what > rosinstall does today. > So if a user wants to add something that would get a same target path as > something he already has, an attempt at merge is made (updating a > version), else that fails. If a user wants to change versions according > to some snapshot, that's also a merge. > The other modifying commands are init, update and regenerate and remove. > > init is like merge, except it requires the target path to be empty, a > ros root to be given, and in that it bootstraps ros > update is like merge, except that it takes no further arguments (however > changing the .rosinstall manually has the same effect as passing certain > arguments). > regenerate is different in that it performs no scm operations. it is > like the "harmless" attempt to repair an environment. > > I'll adapt extend the unit tests for the current version, and then we > may go ahead or reject the REP. > if we reject the REP, I can still embed the functional changes I did to > rosinstall as patches that do not change the syntax, such as > rosinstall --diff > rosinstall --info > > regards, >   Thibault > > > > On 07/06/2011 06:05 PM, Ken Conley wrote: >> So, some quick comments, hopefully more later: >> >> "rosinstall shadow" >>   - we tend to use the nomenclature 'overlay' rather than shadow >> (shadow is behind, overlay is on top) >>   - I would recommend against implementing this right now.  Our >> indexers currently only produce the latest 'trunk' of a resource, >> which will frequently be the wrong resource.  The intent is to update >> the indexer and roslocate command to respect version targets (e.g. >> --distro diamondback), at which point a better version of this command >> -- with different arguments -- could be implemented. >> >> "rosinstall apply" >>   - As the REP itself indicates, I think this really confuses users to >> introduce multiple, nearly identical commands.  It's the problem of >> git, in my opinion, to elevate multiple, slightly different workflows >> to top-level commands, rather than communicating a strong, good >> workflow and demoting special cases to options/etc...  I would >> personally leave apply out and make it an option on add.  The option >> would more strongly communicate the different behavior, IMHO (e.g. >> --replace) >> >> "rosinstall check --repair" >>   - This seems like an unbounded feature, which is difficult for a tool >> like rosinstall that needs to be stable.  I would break it out to a >> separate tool.  Based on my own experience with roswtf, it's hard to >> write and maintain tools that attempt to fix user's problems for them. >> >> "rosinstall change-ros" >>   - I am uncertain of the driving U13 use case.  Now that ros is >> separated into ros and ros_comm stacks, changing ros isn't effective >> and can put you in a bad state.  Personally, more common for me is >> changing distro from diamondback<->unstable.  That is much more >> difficult to automate with rosinstall as it can be very install >> specific (e.g. debian underlay). >> >> Basically, I think you've done good work with this, but I would shoot >> for a smaller initial command set that is well focused, then >> introducing too much too soon. >> >> cheers, >> Ken >> >> >> >> >> On Thu, Jun 30, 2011 at 1:33 PM, Thibault Kruse  wrote: >>> Sorry, work is slow on REP 110. >>> >>> I created a second repo at >>> http://code.in.tum.de/indefero/index.php//p/rosrelease2/ >>> containing ros_release with some small changes i required for >>> rosinstall. You may pull from there (preferably into a folder where you >>> svn checked-out ros_release), and in the rosinstall subfolder, pull from >>> the >>> http://code.in.tum.de/indefero/index.php//p/rosinstall2/ >>> repo my version. There is still a rosenv (rosinstall2) and a rosinstall >>> script, where the rosinstall script is the original rosinstall plus all >>> bugfixes for which I created tickets/patches and which I implemented in >>> the rosenv script (for fair comparison). >>> >>> On my system, what works is to uninstall rosinstall, and then run >>> sudo dpkg -r rosinstall >>> make install >>> >>> in the rosinstall subfolder, simply confirming whatever the python >>> install tool suggests. >>> >>> This copies the (patched) sources from ros_release/vcstools and then >>> installs rosinstall. This is how it already was, I did not change this, >>> I am largely ignorant and confused about python checkinstall. There >>> might be some smarter way to achieve this, but i don't know it. >>> >>> I am slowly implementing sanity checks for rosinstall. I may skip >>> implementing repair actions, as the code may be more of a burden than a >>> blessing and just delay release of the REP. >>> >>> I still do not know whether the REP in the state it is in our repo >>> http://code.in.tum.de/indefero/index.php//p/rosinstall2/source/tree/master/rosinstall-REP.txt >>> is acceptable or needs rework. >>> >>> cheers, >>>    Thibault >>> >>> _______________________________________________ >>> ros-developers mailing list >>> ros-developers@code.ros.org >>> https://code.ros.org/mailman/listinfo/ros-developers >>> >> _______________________________________________ >> ros-developers mailing list >> ros-developers@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-developers > > _______________________________________________ > ros-developers mailing list > ros-developers@code.ros.org > https://code.ros.org/mailman/listinfo/ros-developers > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > _______________________________________________ ros-developers mailing list ros-developers@code.ros.org https://code.ros.org/mailman/listinfo/ros-developers