[ros-users] ROS package git repository conventions?

Ibrahim Awwal ibrahim.awwal at berkeley.edu
Thu Aug 18 04:28:12 UTC 2011


Thanks everyone, all your input was very helpful. I've been away from the
lab for a few weeks so I forgot that there was such a thing as a stack, I
don't know why I didn't realize that was the most logical organizational
unit to map to a git repository. The rosinstall method for tracking
repositories seems perfect; when we make the switch we'll let you know so
that we can take over maintaining the rosinstall file for our repo.

-Ibrahim

On Tue, 16 Aug 2011 13:25:45 -0700, Ken Conley <kwc at willowgarage.com>
wrote:
> Thanks for the great suggestions.  I'm now testing a new version of
> the indexer that downloads N rosinstall files into the combined index.
>  If this new version works, repo maintainers are welcome to take over
> hosting of their rosinstall files.  You can see a list of the ones I'm
> currently testing with here:
> 
> https://code.ros.org/svn/ros/stacks/rosorg/trunk/rosdoc_rosorg/repos/
> 
> These are then indexed here:
> 
>
https://code.ros.org/svn/ros/stacks/rosorg/trunk/rosdoc_rosorg/repos.list
> 
> Another nice aspect of this approach is that the rosinstall file is
> multi-purpose.  Not only does it feed the indexer, but it can
> generally be used with rosinstall to download all stacks in your
> repositories.
> 
>  - Ken
> 
> On Tue, Aug 16, 2011 at 9:30 AM, Ken Conley <kwc at willowgarage.com>
wrote:
>> 2011/8/16 Lorenz Mösenlechner <moesenle at in.tum.de>:
>>> Hi,
>>>
>>> I'm not sure if this approach is really practical. The problem with
>>> git submodules is that they reference a specific revision in another
>>> repository. That means whenever I add a new package to a stack and I
>>> want to have it indexed, I need to make sure that I update the
>>> repository with the submodule, too. The same holds whenever I make an
>>> API change or something that I want to have indexed.
>>
>> Thanks for the explanation.
>>
>>> What about using a magic rosinstall file in a repository. For
>>> instance, if the git repository tum-ros-pkg.git contains a file
>>> tum-ros-pkg.rosinstall on toplevel, could the crawler maybe use it to
>>> find the actual repositories with the stacks?
>>
>> I like this implementation approach, though I would make it less
>> magical.  Instead of pointing to tum-ros-pkg.git, we could have a
>> meta-indexer that listed these rosinstall files and produce a combined
>> index.
>>
>> Overall, it doesn't suffer from the checkout naming issues and works
>> for any git/hg/svn/bzr-based repository.  In the future, it
>> potentially also allows repo maintainers to produce rosinstall index
>> files for different ROS distributions.
>>
>>  - Ken
>>
>>> Lorenz
>>>
>>>> On Tue, Aug 16, 2011 at 9:04 AM, Lorenzo Riano
>>>> <lorenzo.riano at gmail.com> wrote:
>>>> > Ok, a more practical example:
>>>> >
>>>> > We at Ulster have a shared account on GitHub called 
>>>> > "uu-isrc-robotics". We
>>>> > started with one repository, called uu-isrc-robotics-pr2-pkgs that
>>>> > contained
>>>> > one stack and some packages in the stack. When we released the
>>>> > rubik's cube
>>>> > solver code, I decided to keep it separate from the other stacks
(to
>>>> > avoid
>>>> > people having to pull a lot of code they don't need). I guess this
>>>> > will
>>>> > become common practice in the future, say Berkely stack becomes a
>>>> > collection
>>>> > of several stacks hosted by the same user (but not in the same
>>>> > repository).
>>>> >
>>>> > Now the problem is that every time we release a new stack, we'll
>>>> > have to
>>>> > notify ros-users, get a confirmation, and wait for the the crawler
>>>> > to find
>>>> > the new stack. So my idea would be to have a crawler that monitors
a
>>>> > user
>>>> > account (for example "uu-isrc-robotics") and automatically finds
and
>>>> > indexes
>>>> > which repositories contain stacks.
>>>> >
>>>> > I hope it makes sense now
>>>>
>>>> The above implementation that is a bit trickier, as it involves the
>>>> crawler having explicit capabilities with github.  As the crawler is
>>>> just a rosinstall file, this requires some big feature additions.
>>>>
>>>> Also, the major issue I see is that the implicit mapping of the
>>>> repository name to a checkout name is not correct.  This is important
>>>> as ROS sets the stack name based on the directory name.
>>>>
>>>> As an alternative, you could just create a repository called
>>>> 'uu-isrc-robotics'.  When you create a new stack repo on git, you
>>>> could add it as a submodule.  Our indexer would only have to know
>>>> about uu-isrc-robotics and would get updates whenever you update that
>>>> repo.   Still no need to notify ros-users, and it has an explicit
>>>> opt-in for each repository -- for example, for most github accounts,
>>>> there are several non-ROS-related repositories as well.
>>>>
>>>> So my question was basically, why the github-centric approach,
instead
>>>> of just git submodules?  I don't use git, so I don't know if there
are
>>>> some deficiencies with submodules that could be corrected with the
>>>> github approach.
>>>>
>>>>  - Ken
>>>>
>>>>
>>>> >
>>>> > On 16 August 2011 16:52, Ken Conley <kwc at willowgarage.com> wrote:
>>>> >>
>>>> >> On Tue, Aug 16, 2011 at 7:24 AM, Lorenzo Riano
>>>> >> <lorenzo.riano at gmail.com>
>>>> >> wrote:
>>>> >> > I have received some emails of people who wanted to run the
>>>> >> > rubik's cube
>>>> >> > stack, but they didn't want to pull the whole UU stack just
>>>> >> > because the
>>>> >> > rubik's stack depends on a single package in UU (OK it's a bit
>>>> >> > complicated...)
>>>> >> >
>>>> >> > Anyway, what I think would be interesting is to have the ROS
>>>> >> > indexer
>>>> >> > scan
>>>> >> > the packages of a (for example) GitHub user and retrieve all the
>>>> >> > stacks.
>>>> >> > This way Berkley, TUM, UU and so on will have an account on
>>>> >> > GitHub (or
>>>> >> > google code or whatever) with several repositories, each of them
>>>> >> > being a
>>>> >> > stack.
>>>> >>
>>>> >> What is the argument for this over, say, git submodules?  There
>>>> >> are
>>>> >> many issues on the implementation side of doing this, so I'm
>>>> >> wondering
>>>> >> what the advantage would be.
>>>> >>
>>>> >>  - Ken
>>>> >>
>>>> >> >
>>>> >> > I hope this makes sense...
>>>> >> >
>>>> >> > Lorenzo
>>>> >> >
>>>> >> > On 15 August 2011 21:05, Ibrahim Awwal
>>>> >> > <ibrahim.awwal at berkeley.edu>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> Hi ROS users,
>>>> >> >>
>>>> >> >> We're considering/planning on switching to git/github for the
>>>> >> >> Berkeley
>>>> >> >> ROS package. What are the conventions on structure and such
that
>>>> >> >> people
>>>> >> >> are using? With svn we have a url like this
>>>> >> >> http://ros.berkeley.edu/svn/berkeley-ros-pkg/ with all our
>>>> >> >> stuff, with
>>>> >> >> git would it be preferrable to have one repo called
>>>> >> >> berkeley-ros-pkg or
>>>> >> >> separate repos for each stack and maybe link them together with
>>>> >> >> submodules? What are other people doing that are using git? It
>>>> >> >> seems
>>>> >> >> like at least TUM is using separate repos per project on their
>>>> >> >> git repo
>>>> >> >> (which seems to be the much more sane route) but I was
wondering
>>>> >> >> if
>>>> >> >> there was any requirement to have something called foo-ros-pkg
>>>> >> >> somewhere. Thanks,
>>>> >> >>
>>>> >> >> -Ibrahim
>>>> >> >> _______________________________________________
>>>> >> >> ros-users mailing list
>>>> >> >> ros-users at code.ros.org
>>>> >> >> https://code.ros.org/mailman/listinfo/ros-users
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > phone: +44 (0)28 71375187
>>>> >> > email: l.riano at ulster.ac.uk, lorenzo.riano at gmail.com
>>>> >> > skype: lorenzo.riano
>>>> >> >
>>>> >> > Webpage: http://isrc.ulster.ac.uk/Staff/LRiano/Contact.html
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > ros-users mailing list
>>>> >> > ros-users at code.ros.org
>>>> >> > https://code.ros.org/mailman/listinfo/ros-users
>>>> >> >
>>>> >> >
>>>> >> _______________________________________________
>>>> >> ros-users mailing list
>>>> >> ros-users at code.ros.org
>>>> >> https://code.ros.org/mailman/listinfo/ros-users
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > phone: +44 (0)28 71375187
>>>> > email: l.riano at ulster.ac.uk, lorenzo.riano at gmail.com
>>>> > skype: lorenzo.riano
>>>> >
>>>> > Webpage: http://isrc.ulster.ac.uk/Staff/LRiano/Contact.html
>>>> >
>>>> > _______________________________________________
>>>> > ros-users mailing list
>>>> > ros-users at code.ros.org
>>>> > https://code.ros.org/mailman/listinfo/ros-users
>>>> >
>>>> >
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>
>>> --
>>> Lorenz Mösenlechner            | moesenle at in.tum.de
>>> Technische Universität München | Boltzmannstr. 3
>>> 85748 Garching bei München     | Germany
>>> http://ias.cs.tum.edu/         | Tel: +49 (89) 289-26910
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

-- 
-Ibrahim Awwal



More information about the ros-users mailing list