On Thu, Jan 20, 2011 at 5:49 PM, Ken Tossell <ktossell@umd.edu> wrote:
> On Wed, Jan 19, 2011 at 4:20 PM, Ken Conley <kwc@willowgarage.com> wrote:
>> Our indexer just uses rosinstall, so that is one way of debugging from
>> your end any potential setups.
>
> rosinstall here (0.5.12) had no problem fetching the repository:
>
> - git: {local-name: umd-ros-pkg, uri:
> 'git://ram.umd.edu/umd-ros-pkg-test.git', version: master} [git 1.7.0.4]
>> submodules are still immature.  For example, they aren't available on
>> pre-Lucid Ubuntu machines.
>
> If ros.org could direct users to the subrepositories when they inquire about
> stacks or packages (wiki, roslocate, etc.), would that help to avoid added
> confusion? Something like the following (code attached):
>
> repo.yaml:
> name: umd-ros-pkg-test
> packages:
>  gps_common: {authors: Ken Tossell, brief: gps_common, license: BSD, stack:
> gps_umd,
>    url: 'http://ros.org/wiki/gps_common', vcs_uri:
> 'git://ram.umd.edu/ros/gps_umd.git'}
>  gpsd_client: {authors: 'Rob Thomson, Ken Tossell', brief: gpsd_client,
> license: BSD,
>    stack: gps_umd, url: 'http://ros.org/wiki/gpsd_client', vcs_uri:
> 'git://ram.umd.edu/ros/gps_umd.git'}
>  pkg_in_main_repo: {authors: '', brief: pkg_in_main_repo, license: BSD,
> stack: stack_in_main_repo,
>    url: 'http://ros.org/wiki/pkg_in_main_repo', vcs_uri:
> 'git://ram.umd.edu/umd-ros-pkg-test.git'}
>  some_imported_pkg: {authors: '', brief: some_imported_pkg, license: BSD,
> stack: test_ros,
>    url: 'http://ros.org/wiki/some_imported_pkg', vcs_uri:
> 'git://ram.umd.edu/ros/test_ros'}
> stacks:
>  gps_umd:
>    authors: Ken Tossell
>    brief: gps_umd
>    description: GPS messages and libraries
>    license: BSD
>    packages: [gpsd_client, gps_common]
>    url: http://ros.org/wiki/gps_umd
>    vcs_uri: git://ram.umd.edu/ros/gps_umd.git
>  stack_in_main_repo:
>    authors: Maintained by
>    brief: stack_in_main_repo
>    description: stack_in_main_repo
>    license: BSD
>    packages: [pkg_in_main_repo]
>    url: http://ros.org/wiki/stack_in_main_repo
>    vcs_uri: git://ram.umd.edu/umd-ros-pkg-test.git
>  test_ros:
>    authors: Maintained by
>    brief: test_ros
>    description: test_ros
>    license: ''
>    packages: [some_imported_pkg]
>    url: http://ros.org/wiki/test_ros
>    vcs_uri: git://ram.umd.edu/ros/test_ros
> vcs: {type: git, uri: 'git://ram.umd.edu/umd-ros-pkg-test.git'}
>
> [similar effect for megamanifest/megastack]
> Then the git repositories that use submodules would probably need to move
> all of their stacks into submodules, so that users wouldn't have any need to
> install both sub_repo.git (for imported_stack) and main_repo.git (for
> stack_in_main_repo), ending up with two copies of imported_stack.

Thanks for the patches -- can you create a ticket with them so we can
have a longer-term discussion? There are multiple actual features in
the patches, so it would be good to discuss each.

Separately, the more I think about this thread, the more I think that
using submodules to create virtual repositories may not be a good
idea.  There is greater potential to have duplicated code in the
system because it creates duplicate entrypoints.  Also, from our own
experience with SVN externals, the value of it decreases over time.

When our repositories were first starting out, it seemed meaningful to
want to get 'all' of the code.  But, as tools like rosinstall and our
debian build system matured, and as the amount of code in our
repositories increased, the SVN externals became less necessary.
Similarly, as we have started using more external stacks and non-SVN
stacks, they stopped being a useful way to do configuration.  In the
end, you need a rosinstall file or debs to get all of the code you
need.  Once you cross this line, the externals just became an extra
thing to maintain, and it was just easier to use the other mechanisms
(rosinstall/debs/variants) to accomplish the same thing.

On a separate note, one of the items on our list for electric is to
give repository maintainers control over their own index file, which
will be a rosinstall file.  We will also have tools that will
automatically generate an index for any stack included in the
rosdistro file.  The external release process was, in part, an effort
to start helping us shift our indexing infrastructure it is become too
difficult for me to keep up with the rapid rate of new repos.

 - Ken