HgNested plugin on 2.x

[mharb...@gmail.com]

Hello,

We used the scm-hgnested-plugin with 1.5.x to keep Mercurial subrepos in sync on the server by redirecting all references to each single subrepo instance.  I've played with 2.39 a bit, looking to upgrade, but I don't see this plugin (or any signs it was folded into the main hg plugin).  Was this not ported to 2.x because of lack of user interest, architecture changes, or something else?  I'm wondering how hard it would be to bring back.

--Matt

[Christoph Loose]

Hi Matt,

thank you for your message. We would love to see you migrated on 2.39 of SCM-Manager!

Actually the hg nested plugin isn't ported into version 2.X of SCM-Manager yet. But we have already planned a story in our next sprint to bring it back.

Stay tuned.

Best,

Christoph

[mharb...@gmail.com]

Hi Christoph,

Thanks for taking this on.  I was struggling to adjust the old repo and get it to build.  Do you have an estimated release date?  It looks like releases are on a ~6 week cadence, but having  a target date would help me plan time for doing the migration work.

Thanks,

--Matt

[florian....@cloudogu.com]

Hi Matt,

The functionality of subrepositories being identified as such and resolved in the frontend is implemented in the 2.x core of SCMM. Additional configuration is thus no longer necessary.

In the code overview of version 2.x, submodules (Git), subrepositories (Hg) and externals (Svn) are marked with an icon of an outlined folder and linked if the url is resolvable.

Or do you need an explicit redirect? If so, a more detailed description of your usecase would help me to understand and to extend the function to fit your needs.

We have decided not to release a new version each sprint, but only at the completion of larger features. Therefore I can't give you a exact release date.

I hope I was able to help you in some way,

Florian 

[mharb...@gmail.com]

Hi Florian,

I'm not sure what resolution in the frontend you're referring to that makes additional configuration unnecessary, but it doesn't sound like the same functionality as the plugin provided in 1.x- IDK how that could be automatic (though that would be nice- maybe the Mercurial clone pooling functionality would work, but I suspect the old redirect is simpler and more flexible).

The use case is basically this- 2 top level C projects, and a subrepo of header files named "include".  The canonical layout, both locally and in the wire protocol is thus:

    project1

    project1/include

    project2

    project2/include

Normally,  project1/include and project2/include are separate clones on the server, so if a user commits to project1/include locally and pushes, somebody pulling project2/include doesn't see those new commits.  The really nice thing about the 1.x plugin was that we configured the include subrepo to point to the same copy on the server:

    project1

    project1/include (3xx redirect to subrepos/include)

    project2

    project2/include (3xx redirect to subrepos/include)

    subrepos/include

With that, there's only one clone of the subrepo and any push to project1/include or project2/include would be visible when pulling from the other path.

We could get the same functionality by logging into the server and using the share extension, but it would be nicer using the web interface, and it's probably a bad idea to poke around in the directory tree owned by SCM Manager.

Does that clarify the workflow?

Thanks,

--Matt

[florian....@cloudogu.com]

Hi Matt,

Thanks for your response! This does clarify your workflow. We'll recreate that on our end and get back to you.

Nested repositories are defined in the `.hgsub`. This file is evaluated by the SCMM and the specified paths are used to mark folders in the filetree as subRepository.

Regards,

Florian