[Submin 0]

I don't have a Russian keyboard so I will use English. Fill free to reply in Russian.

We were using Hg for a while for our small team version control. The order is to migrate to something else. It is not really important is it free or commercial. What is important to have a distributed cloud-based platform with the ability to support sub-repositories.  If you want to say GIT is the one then I don't know how to apply it correctly. The reason is that what is called submodules is being cloned within the project subfolder and thus creates a bunch of copies of the master repo. When you have quite a few projects on the same PC managing all of them becomes a nightmare at least for me. I'm not a Git guru so maybe it is my problem, not GITs. I do recall that about 10 years ago GIT could do the trick of having a single repo linked to a bunch of projects but it has changed a lot since. 

Could you guys please advise what should we look at or what is the correct technology to use for that workflow? Here is a very brief example: Let's say there is some HAL. Then there are several example projects showing how to use apply this HAL. Of course, with the time HAL is changing but the requirement still has old example projects linked to the old version of HAL, not a copy but exactly the reference to the repo. 

As I mentioned, I'm not really qualified to discuss Version control tools and asking you to excuse me and or I can serve as a translator between you and our team member responsible for the VC system.

Thank you in advance.

[dxp 33]

15 часов назад, Submin сказал:

The reason is that what is called submodules is being cloned within the project subfolder and thus creates a bunch of copies of the master repo. When you have quite a few projects on the same PC managing all of them becomes a nightmare at least for me.

Почему копии подмодуля в разных проектах становятся кошмаром? У вас каждый проект содержит всё, что ему надо, включая код из сторонних репов - подмодули. Если вы нашли ошибку или что-то поправили в подмодуле, просто закиньте это на удалённый реп, и оттуда возьмите в другой проект. Как раз эта схема позволяет вести проекты раздельно, исправляя ошибки и дополняя функциональность подмодулей. Если нужны разные версии подмодулей, то просто переключаете в каждом конкретном проекте подмодуль на нужную ветку. 

 

Если же вам не нравится, что куча копий одного и того же, и вам не надо раздельно это править, а достаточно просто иметь один исходник, то не втягивайте этот код в проект подмодулями, а просто вытяните его в отдельное место как стороннюю библиотеку, а в проектах просто пропишите пути к этой библиотеке (лучше через переменные окружения). Так у вас будет одна-единственная библиотека на все проекты. Гит тут никак не мешает и позволяет организовать любой маршрут.

[Submin 0]

So after long internal discussions we're going to try using a project as a main repo and clone other independent repos to whatever location/folders tree structure required by this particular project. The challenge will be how to track all those folders and repos(or actually subrepos in relation to the main project) and their relations. Is my explanation clear? Do you have any suggestions and/or tools which can help?

Thanks.

[dxp 33]

Если у вас сторонний код общий для многих проектов, и все они (проекты) ссылаются на одну и ту же реализацию (версию) этого стороннего кода, то просто положить этот куда куда-то в известное место и прописать пути из проекта к этому месту. 

 

Если у вас сторонний код общий для многих проектов, и все они (проекты) ссылаются на разные реализации (версии) этого стороннего кода, то очевидно, что шарить одно и то же не получится и надо как минимум расплодить эти места, положив в каждое из них необходимую реализацию. Но в этом случае это почти то же самое, что положить этот сторонний код в дерево проекта в виде сабмодуля. И в этом случае автоматически в основном проекте будет фиксироваться актуальная версия (ссылка на комит) стороннего кода.

 

Можно комбинировать оба подхода. 

[Submin 0]

Submodule the way it is implemented in GIT does not work. Distributed repos expected to do the job. Is there any tool to manage multiple and nested repos?

 

[dxp 33]

Я не понимаю, почему подмодули у вас не работают. У всех работают, а у вас нет. Вы не объясняете, что именно там не работает, а я не телепат. Не нравится git, используйте другую систему; hg, svn, perforce...

[Submin 0]

This is an example of dependencies. For example Repo1 depends on Repos 3,5,6 and so on...

[dxp 33]

20 часов назад, Submin сказал:

This is an example of dependencies. For example Repo1 depends on Repos 3,5,6 and so on...

И? И почему Repos 3,5,6 and so on... не могут быть подмодулями Repo1?

[Submin 0]

Take it as simple as just they can't. At least one reason: GIT sub-modules are creating/demanding their one file tree structure that is NOT suitable for the project. Using independent sub-repos does not require such a hassle.  

If you have something to offer then please do if not then thank you for trying to help. 

Изменено 13 июня, 2020 пользователем Submin

[Raven 8]

17 hours ago, Submin said:

Take it as simple as just they can't. At least one reason: GIT sub-modules are creating/demanding their one file tree structure that is NOT suitable for the project. Using independent sub-repos does not require such a hassle.  

If you have something to offer then please do if not then thank you for trying to help. 

 

Как насчет того, чтобы гармонизировать свой код из этих субмодулей с возможностями, скажем, GIT?

Я имею в виду следующее:

1. Создается иерархия субмодулей почти согласно приведенной картинке. С тем отличием, что на стрелки, идущие от REPO5, не обращаем пока внимание.

2. А теперь зависимости/стрелки REPO5 реализуем корректировкой ссылок на файлы:

      - ../REPO6/src

      - ../REPO3

      - ../REPO3/REPO4/src

и т.д.

Дублирования не возникает. Местоположение нужных репо легко задается переменными типа REPO_xx_HOME with relative path. Через них и нужно оформлять зависимости в коде. Тогда, кстати, можно даже линейную структуру каталогов использовать, а не иерархическую.

[Submin 0]

@Raven,

I'd appreciate if you elaborate your idea in more details - I'm not sure that understood it. As I mentioned in the very first post, I'm not strong with SVC and GIT as a tool. What I do know, that GIT indeed will create the folder structures as you said but this is NOT suitable for the project. If it is possible to fool git - then it is great, doing the same with the actual project is unacceptable: tool is used by the project not the inverse. 

[Raven 8]

On 6/15/2020 at 4:10 AM, Submin said:

 tool is used by the project not the inverse. 

Я предлагал как раз обратное - повернуть ваш проект лицом к инструменту (повернись, избушка, ко мне лицом, к лесу задом), предположив, что для вас важнее решить задачу, и для этого можно было бы двигаться с обеих сторон (как со стороны проекта, так и со стороны CVS).

Если подход со стороны проекта изменять нельзя, остается посоветовать вам пройтись по другим современным CVS - проверить, как они работают с субмодулями и что у них с дублированием репозиториев, не так уж долго (современные CVS можно пересчитать пальцами одной руки).

[Submin 0]

@Raven,

Well, I don't think that anything but GIT and Hg are supporting submodules/subrepos. GIT submodule is not acceptable because it requires it's on file tree(does not meet the requirements) and some other people on the project dislike Hg... I am not aware of any other distributed SVC.

Does anyone know some kind of a system which can manage INDEPENDENT GIT repos, tracked and managed by this system externally in relation to GIT? 

 

[Raven 8]

12 hours ago, Submin said:

Does anyone know some kind of a system which can manage INDEPENDENT GIT repos, tracked and managed by this system externally in relation to GIT?

Если я правильно понял, то вы хотите, чтобы у репозитория с базой данных всех коммитов была возможность делать несколько разных рабочих копий, с их собственным отображаемым в каждое из них branch, собственным файловым под-деревом, отвечающим этому branch, историей изменений и т.п.

 

C точки зрения GIT это означает, что нужно поддерживать не 1, а N разных областей индексирования (или как оно там называется в оригинале - это внутренний механизм, отслеживающий изменения в мониторируемом коде ДО того, как будет произведен commit этих изменений). Не думаю, что это (N областей индексирования) поддерживается GIT концептуально на данный момент, а значит, никаких программных инструментов, реализующих это, не может быть по определению.

 

Может ли такое делать какая-то другая CVS - я не знаю.  Кроме Hg есть еще Bazaar - не проверяли его?

[Submin 0]

@Raven I'm not sure that we're on the same page. I have an independent repo. GIT takes care about it. There is another independent repo which depends on the first one. So in the second I can use a certain commit. Because both repos are independent, I can clone the first one wherever I need, modify it and commit. Then in the second all I need to do is to change the commit. If the first repo was updated outside my project, I can test it with the latest commit or may ignore it. Is it clear?

If this idea is understood and seems to be matching my requirements, it there any tool that can be configured for such independent repo dependencies and keep track of of the changes?