Hi guys, would it be possible to include the feature to patch the code in rosinstall? D. On Wed, Jul 20, 2011 at 11:12 AM, Tully Foote wrote: > Hi, > > I think that the SCM syntax is good.  As proposed info and diff are good > extensions.  And as Dave suggested adding status would be good. > > snapshot is also probably a better name than --generate-versioned...  we can > add that as an alias. > > The other commands start to get into configuration management and although > they share a lot of the names of SCM commands they actually are noteably > different. init, add, remove, apply, update, check.  Inventing a whole new > syntax is something we should not do lightly especially if there's other > solutions.  Most of the ordering ones can be done more easily by using an > editor and cut and paste without learning a new command set.  The > differentiation between init and update is not really required in this > case. > > I would suggest that we take the configuration methods you have layed out > here and use them in the rosws/rosworkspace discussion which Brian started. > And pare down the existing REP 110 draft to be just the SCM commands status, > diff, and info. > > Tully > > On Wed, Jul 20, 2011 at 9:25 AM, Thibault Kruse wrote: >> >> 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 > > > > -- > Tully Foote > Systems Engineer > Willow Garage, Inc. > tfoote@willowgarage.com > (650) 475-2827 > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > -- MSc. Dejan Pangercic PhD Student/Researcher Intelligent Autonomous Systems Group Technische Universität München Telephone: +49 (89) 289-26908 E-Mail: dejan.pangercic@cs.tum.edu WWW: http://ias.cs.tum.edu/people/pangercic