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
(text/plain)