Dropping support for non-git repository types (svn, hg, etc.)

[ijnek]

There is currently not a single package in all active distros (noetic, melodic, foxy, galactic, humble or rolling) that uses a repository type other than git (so svnor hg).

Dropping support for such less popular (and perhaps not-recenlty tested) repository types could reduce the maintenance burden and help the community contribute to bloom. This would also somewhat reduce the cases we have to cover for porting bloom/FirstTimeRelease to ROS2 docs (ros2/ros2_documentation#2375)

What are the thoughts of the maintainers?

[ijnek]

Do any of the maintainers have opinions on this?

[danthony06]

It's possible to use bloom to release to non-public repositories, so it's kind of hard to say that this repository types aren't being used with bloom.

[nuclearsandwich]

Do any of the maintainers have opinions on this?

I think that there is demonstrable value in not letting Git, or GitHub become a monoculture.
Much of bloom's optimal workflows only support Git repositories on GitHub currently but the tool can still be used for both repositories elsewhere and other version control formats.

ROS itself began as a subversion project and was at one point hosted on Google Code. Which is to say that Git and GitHub may feel like the only game in town now but in another ten years' time we could be seeing a brand new ascendant version control workflow and maintaining support for multiple version control systems will make it easier to integrate those in the future.

If bzr is still supported, I could see deprecating that support since I think that the upstream project has also not seen a new release since 2016 (although it could just be "done").

Likewise I could also see deprecating subversion support if and only if it significantly reduces the amount of code in bloom.

I think mercurial should still be maintained both because it has been used with ROS packages in the last couple of years (I can't recall off the top of my head but I know at least one major external package was using it before Bitbucket dropped mercurial support) and because it keeps us honest regarding bloom's design goal of being modular toward version control systems.

[ijnek]

Thanks @danthony06 and @nuclearsandwich, I believe a deprecation cycle would be good such that the community can complain about the removal nice and early if they do still depend on the other vcs. I can imagine some unhappy community members if we suddenly drop it out of nowhere.

So, are you happy with two deprecation PRs for bzr and maybe svn? What about tar? I don't know too much about that one.

[ijnek]

A you happy with two deprecation PRs for bzr and maybe svn? What about tar? I don't know too much about that one.

@nuclearsandwich

[nuclearsandwich]

So, are you happy with two deprecation PRs for bzr and maybe svn? What about tar? I don't know too much about that one.

I scanned the current state of ros/rosdistro for version control systems used:

❯ rg -c '^      type: bzr'
# no results

❯ rg -c '^      type: svn'
jade/distribution.yaml:1
groovy/distribution.yaml:73
hydro/distribution.yaml:7
indigo/distribution.yaml:1

❯ rg -c '^      type: hg'
hydro/distribution.yaml:6
jade/distribution.yaml:4
lunar/distribution.yaml:3
melodic/distribution.yaml:2
groovy/distribution.yaml:38
indigo/distribution.yaml:24
kinetic/distribution.yaml:2

❯ rg -c '^      type: git'
humble/distribution.yaml:746
foxy/distribution.yaml:833
rolling/distribution.yaml:717
jade/distribution.yaml:877
lunar/distribution.yaml:729
groovy/distribution.yaml:551
galactic/distribution.yaml:725
bouncy/distribution.yaml:143
eloquent/distribution.yaml:392
dashing/distribution.yaml:427
noetic/distribution.yaml:1321
melodic/distribution.yaml:1751
indigo/distribution.yaml:2021
kinetic/distribution.yaml:2081
hydro/distribution.yaml:1011
crystal/distribution.yaml:235
ardent/distribution.yaml:69

rg -c '^      type: tar'
# no results

Given the above, I think a deprecation PR for bzr would be very welcome. Likewise I think svn deprecation would be alright although I'm not strongly in favor (again unless it simplifies code considerably). There are two mercurial repositories listed in Melodic, a currently active distribution so I'm still in favor of maintaining it even beyond the EOL for Melodic.

I am not sure I realized bloom supported tar archives but I assume that support is for projects which do "source drop" style releases and don't have public version control. That support should probably remain even if it isn't in use.