Suggestions for Repository Structure

[Dave.P]

I’m looking for some advice about setting up Plastic repositories.
 

I’m a member of a five-person developer team that supports a wide range of systems and processes underpinning company operations. I understand the best practice of setting up a Plastic repository for each project. The problem is that much of our work doesn’t fall into clear-cut projects. It makes more sense to group our work into operational areas with related subprojects.
 

If we create a Plastic repository for each subproject, we’re going to have over 70 repositories at the start, and the number will grow over time. This feels like it’s going to be difficult to manage and navigate this many repositories, particularly when it comes to identifying projects that are “sort of” related to each other, but not formally related in the manner that a component is related to an app. In other words, the “sort of” related projects don’t warrant Xlinks, because they’re not sharing code, but they have significant operational relationships.
 

If we create repositories for operational groups, we’re going to have about 15 repositories, which is very manageable. The problem here is that many of the repositories are going to have a large and growing number of subprojects, which is going to make the workspaces messy. We are migrating from Subversion, where it’s possible to have deep hierarchies with workspaces that map to sub-trees, and the thought of having workspaces in Plastic that include the equivalent of many sub-trees, all the time, is not very popular.
 

One solution I’ve considered is creating 15 “operational” repositories, and creating main branches in each repository for subprojects. Schematically, it would look like this:
Fulfillment (repository)
  Coupons (main branch)
    -Campaign 1
    -Campaign 2
  ID Cards (main branch)
  Kits (main branch)
    -Market segment 1
    -Market segment 2
 

This seems like it might meet our requirements: We’ll have a manageable number of repositories, the operationally-related subprojects will reside together, and workspaces will contain the content of branches (subprojects), rather than the entire repository.
 

Has anyone tried this? Will this approach lead to problems down the road?
 

Thanks very much for any advice or suggestions you can offer.

[calbzam]

Hi,

 

As you commented, one repository per project should be the best decision (at least if you are thinking on using Xlinks to share the repository content), but not always the most confortable when you handle a lot of repositories.

 

Recently we have release on Plastic 5.4 a feature that you may like:

 

C:\>cm mkrep localhost:8084 Fulfillment

 

C:\>cm mkrep localhost:8084 Fulfillment/Coupons

 

C:\>cm lrep

 1 default localhost:8084

 2 Fulfillment localhost:8084

 2_1 Fulfillment/Coupons localhost:8084

 

This way, you can create a more organized subrepository list. Does it fit in your scenario?

 

Regards,

Carlos

[Dave.P]

Thanks. That looks like it might work.

 

Which release has the functionality? We have Release 5.0.44.555 installed, and when I executed the command I got the error " Repository name cannot contain any character of: @#/:"?' ".

[calbzam]

Hi,

 

You need Plastic SCM 5.4 (under labs Downloads section). I think the last 5.4 is: 5.4.9.560 (2014.04.23) (Ankara)

 

Regards,

Carlos

[psantosl]

Yep, Plastic 5.4 is the version receiving most of the active development. It is stable in terms of functionality although its API is subject to change.

 

Most of the largest (>200) teams evaluating Plastic right now to move to production are using 5.4, so no worries (and we do use it ourselves here too, for more than 12 months already).

[cidico]

Hi Pablo!

 

You should release a "bleeding edge" section for users like me to use it too!!!

 

What do you think?

[StevenTCramer@gmail.com]

 

C:\>cm mkrep localhost:8084 Fulfillment/Coupons

 

 

So could we add a treeview on the repository Gui to show the organization?  When I create a workspace for a the parent repo "Fulfillment"  it doesn't auto create an xlink workspace.  Should it?

[calbzam]

Hi,

 

- A tree view for the repositories is something we have in our road map. This way, you could organize your repos in a better way.

 

- When you create a "Fulfillment/Coupons" repository, a workspace is not created. Actually, when you create a repository on Plastic, a workspace is not created by default, you will need to create it only in case it´s necessary.

 

Regards,

Carlos