Revision history [back]

This would be technically feasible like this:

• ws1
  • .rosinstall
  • repo1
  • repo2
• ws2
  • .rosinstall

in ws2/.rosinstall, you would have elements with relative path local-name, like

- hg:
    local-name: ../ws1/repo1
    uri: xyz
    version: abc
- git:
    local-name: ../ws1/repo2
    ...

Depending on what you are trying to achieve, this might be okay. rosws update should work. However the different localnames are a bit ugly, so this is not a perfect solution.

If you like to hack, you could modify rosinstall/rosws to use a param or read an ENV var to determine the config filename to use, such as

$ export ROSINSTALL_CONFIG_FILENAME=...

Then you could have two different config files in the same workspace folder, which would better capture the semantics of what you explained.

This would be technically feasible like this:

• ws1
  • .rosinstall
  • repo1
  • repo2
• ws2
  • .rosinstall

in ws2/.rosinstall, you would have elements with relative path local-name, like

- hg:
    local-name: ../ws1/repo1
    uri: xyz
    version: abc
- git:
    local-name: ../ws1/repo2
    ...

Depending on what you are trying to achieve, this might be okay. rosws update should work. However the different localnames are a bit ugly, so this is not a perfect solution.

If you like to hack, you could modify rosinstall/rosws to use a param or read an ENV var to determine the config filename to use, such as

$ export ROSINSTALL_CONFIG_FILENAME=...

Then you could have two different config files in the same workspace folder, which would better capture the semantics of what you explained.

This would be technically feasible like this:

• ws1
  • .rosinstall
  • repo1
  • repo2
• ws2
  • .rosinstall

in ws2/.rosinstall, you would have elements with relative path local-name, like

- hg:
    local-name: ../ws1/repo1
    uri: xyz
    version: abc
- git:
    local-name: ../ws1/repo2
    ...

Depending on what you are trying to achieve, this might be okay. rosws update should work. However the different localnames are a bit ugly, so this is not a perfect solution.

If you like to hack, you could modify rosinstall/rosws to use a param or read an ENV var to determine the config filename to use, such as

$ export ROSINSTALL_CONFIG_FILENAME=...

Then you could have two different config files in the same workspace folder, which would better capture the semantics of what you explained.

EDIT: On Unix Unix/linux plattforms you can also use softlinks to mirror a directory structure

• ws1
  • .rosinstall
  • repo1
  • repo2
• ws2
  • .rosinstall
  • repo1 -> ../ws1/repo1

Then the .rosinstall files would look identical for the entries they share.

BTW, using 'other' elements tells rosws to ignore an entry for update.