Any caveats to using many levels of repositories?

[tciz_plastic]

Hello,

Having a large number of repositories we intend to create many 'levels' by using the '/' character in repository names to take advantage of the tree view in Repositories screen, such as:

AAA

-- AAA/BBB

---- AAA/BBB/CCC

---- AAA/BBB/CCC/DDD

-- AAA/XXX

...

 

I haven't been able to find a specification of this feature in the documentation -sorry if I missed. Before setting up our repos like this, I would like to find out if there are any points to watch out for in such design. For example:

- Is there a limit to the number of levels (i.e. depth)?

- Are there any 'gotcha's with renaming a repo in this structure?

For example, renaming a repo  that has sub-repos? as in AAA/BBB/CCC --> AAA/BBB/CCCX

Or moving a sub-repo one level up? AAA/BBB/CCC/R1 --> AAA/BBB/R1

The reason for this question is that I found out the "Root repositories cannot be converted into modules" restriction by experiment (discussed here).

 

Briefly, could you please let me know if there would be any other restrictions on freely re-structuring this hierarchy if the need arises later?

I hope that makes sense.

 

Thank you for any feedback.

Kind regards,

Engin.

 

 

 

 

 

[calbzam]

Hi,

From our release notes:

[New] 5.4.16.688

Now a full hierarchy of submodules can be added. It is possible to have repositories as follow:

default/codice
default/codice/plasticscm
default/codice/plasticscm/windowsgui
default/codice/semanticmerge

Before only 1 level of submodules was allowed, but now a full hierarchy can be created, which is useful when a certain namespace policy must be enforced.

All the submodules inside a given repository are stored inside the same database as the repository, actually using different table name prefixes or schemas in the case of SQL Server.

Remarks:

• A submodule can't be moved to a different repo. It stays on the repo where it was created.
• A submodule can be moved "inside" a different submodule and submodule hierarchies can be freely modified just applying repository rename operations. It means you can start with

 default/codice
 default/codice/plasticscm
 default/codice/plasticscm/windowsgui

And transform the hierarchy as follows:

 default/codice
 default/codice/plasticscm
 default/codice/windowsgui

And even rename "codice" to "plastic-code" and then:

 default/plastic-code
 default/plastic-code/plasticscm
 default/plastic-code/windowsgui

 

• When you delete a submodule, you delete all the submodules inside it!
  • Remember that delete doesn't really remove the submodule, it stays on the database and it is just unlinked from Plastic (as happens with repositories).

• A submodule inherits permissions from its parent submodule. When you move a submodule, the permissions from the new parent will be applied.

 

Best regards,

Carlos.

[tciz_plastic]

Thank you! That's exactly the answer I needed, and it's funny even some of the wording matches with the question.

 

14 hours ago, calbzam said:

All the submodules inside a given repository are stored inside the same database as the repository, actually using different table name prefixes or schemas in the case of SQL Server.

As an additional thought on this, how would having many submodules in a single database perform compared to making each one a separate (top-level) repository?

For instance, should we take that into account for a few thousands of submodules?

 

Kind regards,

Engin

[calbzam]

Hi,

There shouldn't be any performance issue you when using as many submodules as you need. We have big customers with tons of them with no issues so far.

Regards,

Carlos.

[tciz_plastic]

Hi Carlos,

Thank you for all the information.

Kind regards,

Engin

[psantosl]

The only thing that I'd point is that keeping things simple normally helps a lot. So even if you can reach 10-level nesting, I strongly doubt it is really worth.

 

Remember we provide FREE 1-h sessions with product experts just in case you need to go through some details ?

 

https://www.plasticscm.com/download/freetraining/

[tciz_plastic]

Hi Pablo,

I agree with your point. It's not likely that we will actually go deeper than 2 or 3 levels, the question is more about being aware of any limits.

Also thanks for the information, I didn't know about the possibility to have a session with experts. We will keep that in mind.

Regards,

Engin

[M-Pixel]

From a technical perspective, what are the differences between "repositories" and "modules"?  This still hasn't been answered in the above thread.  As the makers of the software, you should be able to fully enumerate this, and I can't think of why you would want to withhold that information by only giving advice for particular use cases.

From a practical perspective, I understand that this feature allows me to use a tree view instead of a list view in the list of repositories.  What else?  That can't possibly be the extent of the practical implications.  If it were, then everything is really just a repo with a different name, and I should be able to rename "A/B" into "C", but it doesn't sound like that's the case given that modules can't be moved into different repos.

[calbzam]

Quote

From a technical perspective, what are the differences between "repositories" and "modules"?  This still hasn't been answered in the above thread.  As the makers of the software, you should be able to fully enumerate this, and I can't think of why you would want to withhold that information by only giving advice for particular use cases.

From my initial message: "All the submodules inside a given repository are stored inside the same database as the repository, actually using different table name prefixes or schemas in the case of SQL Server."

If you are using Jet, you will see a new database folder (same folder name as the parent repo but inclusing a prefix). You can match your database folders with the repo name (including submodules) by running:

cm lrep --format=TABLE

Quote

From a practical perspective, I understand that this feature allows me to use a tree view instead of a list view in the list of repositories.  What else?  That can't possibly be the extent of the practical implications.  If it were, then everything is really just a repo with a different name, and I should be able to rename "A/B" into "C", but it doesn't sound like that's the case given that modules can't be moved into different repos.

As we commented:

• When you delete a submodule, you delete all the submodules inside it!
  • Remember that delete doesn't really remove the submodule, it stays on the database and it is just unlinked from Plastic (as happens with repositories).

• A submodule inherits permissions from its parent submodule. When you move a submodule, the permissions from the new parent will be applied.
• This feature is normally used when you need a more organized repo-subrepo strucuture and it's specially useful when you have tons of repos for a better organization.

[M-Pixel]

Thanks, and I'm sorry for not making those connections myself - it's certainly easier to see it all listed concisely.  I can see how the SQL table implementation detail could be significant to RDBMS backend users.  For Jet, is there any practical difference, or is it simply a restriction that carries over from the need to support RDBMS?  It seems like there wouldn't be any practical difference if they're still being stored in different top-level folders just as top-level repos are (apart from the naming convention of those folders).

 

Quote

Remember that delete doesn't really remove the submodule, it stays on the database and it is just unlinked from Plastic (as happens with repositories).

Is this also true of Jet?  Am I going to waste disk space if I create and delete repositories that are nested instead of top-level?

[calbzam]

In Jet there is not any practical difference for the subrepos (from the user point of view). It's transparent to the user. The only difference is you need to remember to backup all the subrepos (each one is stored on a different folder: "rep1", "rep_1_1", "rep_1_2"... Internally every subrepo has the same structure as a regular repo.

Quote

Is this also true of Jet?  Am I going to waste disk space if I create and delete repositories that are nested instead of top-level?

If you delete a subrepo and you don't need to use the database anymore, you can delete the Jet database folder for this subrepo (keeping the rest). This way, you shouldn't waste any disk space.

Regards,

Carlos.