[ros-users] Developers workflow in ROS repositories

[Jack O'Quin]

On Wed, Aug 31, 2011 at 8:13 AM, Jose Luis Rivero <jrivero at iri.upc.edu> wrote:
> Hi Jeremiah:
>
> On 08/30/2011 07:03 PM, Jeremiah Via wrote:
>>>>
>>>> Normally, related packages are packed together into stacks. When
>>>> a release is done, the stack's version number is increased and
>>>> the current dev-branch (trunk in most cases) is tagged. For
>>>> instance, when the new version 1.3 of stack foo is released, the
>>>> tag tags/foo-1.3 is created. In addition, a branchs named
>>>> according to the ros distro names the release is done against is
>>>> created, e.g. branches/diamondback.
>>>>
>>>
>>> Thanks for the info Lorenz, never heard about that release scripts
>>> before. are there many institution repositories working this way?
>>>
>>> The model sounds quite reasonable but we have seen an inconvenience
>>> to manage developing this way:
>>>
>>> Every time you make a tag (or a branch) subversion is going to copy
>>> the code in the corresponding directories (branches/ tags/) inside
>>> the repo. This means you will have a repo with duplicates
>>> directories for packages in branches/ trunk/ and tags, right?
>>>
>>> Seeing the way rospack finds packages (mostly leaving the
>>> filesystem to decide the order to loop subdirs contained in entries
>>> of ROS_PACKAGE_PATH) if you make something like a roscd, it could
>>> make you to land on branches/ or tags/ instead of desired trunk.
>>
>> You do not normally check out the entire repository. Instead, you
>> check out trunk and use the switch command as necessary:
>>
>> http://svnbook.red-bean.com/en/1.0/re27.html
>>
>> Similarly, when you tag a release, it exists on the repository but
>> not your machine, so you won't run into this problem.
>>
>
> Yup, partial SVN checkouts can drive to a model without this problem.
>
> The point is that currently we have plenty of interdependencies inside
> the stacks/packages from our own repo so this can lead to has several
> partial checkouts (as many as stack dependencies you need) although you
> only develop in one of the stacks.

You can store multiple stacks within the SVN trunk. (That does not
work with git or hg, BTW.)

If you typically work on one stack at a time, consider installing the
latest release versions of everything else and check out only the new
code from trunk.

If you want to regression test against other developers' newest code,
check out your entire trunk and build that.

There are lots of options: rosinstall supports virtually any mixture
of stable and unstable stacks. If you are running Ubuntu, apt-get can
install binary packages of your currently-released stacks.
-- 
 joq