Jump to content
tciz_plastic

Any caveats to using many levels of repositories?

Recommended Posts

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.

 

 

 

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...