SDL2 in ogredeps as a Mercurial subrepo

[holocronweaver]

Hi all.

I recently added SDL2 as a Mercurial subrepo in ogredeps. (https://bitbucket.org/cabalistic/ogredeps)

It was brought to my attention that some users are having trouble using Mercurial subrepos, and that not everyone thinks Mercurial subrepos are a good idea.

Are there any strong opinions on Merucial subrepos, and if so, why? If you feel they shouldn't be used, what alternative method should we use to include SDL2 in ogredeps?

[holocronweaver]

My 2-cents: I come from mostly a git background where I use git submodules extensively to track remote repositories. This works wonderfully in my use cases since the submodules point to a specific commit in the remote repositories, ensuring that everything builds as intended. I thought Mercurial subrepos serve the same purpose, but perhaps I am mistaken or am overlooking some other disadvantage. It was already mentioned in another forum post that Bitbucket does not include subrepos in zip downloads, which is a downside, but I don't think it is a stretch to ask users wanting a fresh source copy to use the version management software already used by OGRE and most OGRE related projects.

The best cross-platform alternative I am aware of in the current context is CMake ExternalProjects which can automate downloading and building an remote Mercurial repo for a specific commit, but my limited experience has shown ExternalProjects to be occasionally buggy, including redownloading large repos for no apparent reason.

[dark_sylinc]

I didn't come up with the ogredeps idea, although I thought it was great.

It was my understanding that ogredeps was there to avoid the hassle of tracking down every single dependency, while making the building of Ogre easy, both for newcomers and veterans.

At first I thought it was bold to copy paste these dependencies; but I've come to understand why. My personal view, subrepos or automatic downloading of external dependencies have the following issues:

• It can fail. Fail to fetch a dependency (technical problem, inexperience, server moved, server is temporarily down). Sure a central ogredeps repo can fail too. But that is something easy to notice. Failure to download one or several sub-projects can be difficult to track down.
• New versions can stop compiling with Ogre, or cause runtime errors, or bugs. This is hard to track down, specially if every subproject is sync'ed in its own version. Having everything "frozen" makes it easier to find out when things break.

The advantage is that updates in the external repos are almost free and instantaneous, but more of a double edged swords. IMHO the problems outweight the benefits (it would be different if this were safety- or security-critical code that needs everything up to date).

When it comes to the particular case of git submodules, my experience isn't good and mimics these articles.
Even Google scrapped them and wrote their own tool (repo)

[al2950]

Dependency management is always difficult! The only experience I have on sub repos is in SVN, and that was not pleasant. I have looked at it for both Hg and Git, and from what I have read its a last resort feature.

I really do not know what the solution is here, but for the record I have had a lot of success with C# and Nuget and I am currently looking at it for my C++ projects. Boost for example is split up nicely into different nuget packages, see here. I know this is not a viable solution for the whole Ogre community but might be for a large portion of it....

[Kojack]

One issue with sub repos: if a user goes to the ogredeps page and does a zip download of the repo, the sub repo isn't included. Only cloning the repo will pull down the sub repo.
(In some situations it's easier to just grab a zip from the home page instead of bothering with source control software)

New versions can stop compiling with Ogre, or cause runtime errors, or bugs. This is hard to track down, specially if every subproject is sync'ed in its own version. Having everything "frozen" makes it easier to find out when things break.

From what I've read, Mercurial sub repos don't automatically sync. Whatever changeset you pushed into the main repo is what you get when you clone the repo. You need to manually sync sub repos individually if you want them to have the latest changeset.
https://mercurial.selenic.com/wiki/Subr ... positories


Sub repos suffer from something that annoys me in my own projects but would have no effect on ogre deps repo: I want multiple sub repos to be able to overlap their directory structures. But git and mercurial don't allow that.

[holocronweaver]

Sorry for the delayed response.

It can fail. Fail to fetch a dependency (technical problem, inexperience, server moved, server is temporarily down).

If we mention the need for hg pull + update in the README, I think it will be ok. As for the server moving or being down, SDL is a large enough project where I don't think that will be an issue as long as we are supporting it in OGRE. So I don't think we need to worry about these in this particular situation. That said, it is easy enough to change the remote repo location, including to a local location.

New versions can stop compiling with Ogre, or cause runtime errors, or bugs. This is hard to track down, specially if every subproject is sync'ed in its own version. Having everything "frozen" makes it easier to find out when things break.

Not sure what you mean by this. Subrepos point to specific commits in the remote repo, so the SDL2 version won't change until the ogredep maintainers change it.
From the documentation: "Subrepos don't automatically track the latest changeset of their sources. Instead, they are updated to the changeset that corresponds with the changeset checked out in the top-level changeset. This is so developers always get a consistent set of compatible code and libraries when they update."

As for those links to articles against submodules / subrepos, I have read 2/3 before, but while I agree with some of their arguments, they don't offer any decent alternatives that fill the requirements subrepos satisfy.

One of the advantages not mentioned here is that subrepos include the full repo history. Also, they make it easy to update remote repos at will, including full hg repo history. It is just a matter of changing a pointer to a different commit. The user could do this if they want to test newer SDL2 versions.

Thus while I agree that subrepos are not perfect, I don't know of a better option in this particular instance.