On 07/21/2011 08:15 PM, Thibault Kruse wrote:
> Thanks Tully for the feedback,
>
> > 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.
>
> True for all but check. Though bzr check exists, but I'd also go with
> rosinstall wtf
>
> I still think "check" may be useful, providing verbose information for
> all that is strange but not dangerous, like
> - stacks mentioned in .rosinstall but missing
> - stacks in ROS_PACKAGE_PATH after ROS_ROOT
> - duplicate URIs
> - different .rosinstall and setup.sh
> I think all future rosinstall should give warnings on such occasions,
> and "check" would be the verbose information about the warnings.
>
> > And as Dave suggested adding status would be good.
>
> I will implement the status command. "info" in its current state already
> shows a flag modified or not, but as a list of modified files, the
> outputs of the scm status commands will have to be post-processed to
> give a useful path.
>
> > 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.
>
> By now, having the user modify his .rosinstall by hand is what covers
> several usecases now anyway in the REP.
> The problem with having an scm like syntax and a powerful ubiquitous
> command for init/add/merge/apply/update is to find a suitable name for
> that command. The word "install" can cover all of those, but "rosinstall
> install" looks silly. I also kept thinking of "dwim" (do what I mean).
> But that is also non-intuitive.
>
> The differentiation between init, update, add, apply, merge, is not
> technically required, it is merely a usability issue.
>
> > 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.
>
> The REP still has to mention the name of the command to use for
> init/add/update/apply/merge.
> And I see no word in English that would serve the purpose (other than dwim).
>
> The alternative is to use rosinstall without further command for that,
> but then the target directory may not be named after one of the other
> commands (or must be "escaped" e.g. as ./diff).
>
> I also still argue for "regenerate" as a harmless way of updating one's
> setup.* files without touching anything else on the filesystem. However
> adding a confirmation questions before any change would make that
> somewhat obsolete.
>
> So I still advocate the commands
> status
> diff
> info
> snapshot
> check/wtf
> [regenerate]
>
> I'll wait for your suggestion, Tully, on how to deal with
> init/add/update/merge as an SCM-like command.
>
>
>
> On 07/20/2011 08:12 PM, 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
> _______________________________________________
> 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