Branching the Repository

[former_member217396]

Hi,

we have currently the requirement, to structure/branch the repository, and especially the PDM-Model according to the customers needs.

The way how the customer is working is the following:

1) they have 3 stages: development, test/consolidation and production

2) in each of the stages they have 4 releases per year

3) each of the releases is divided into logical units of work. They can have 20 of them per release. The problem with the logical units of work is, the elements (tables etc.) can change in more than one  logical unit of work. The simplest example is that one:

- in LUW1, the table A gets modified, a new column X is added

- in LUW2, the same table A gets modified as well, a new column Y is added

So what we have are more or less 3 levels:

- stage

  - release

    - logical unit of work

Of course they are working on more than one release an more than one logical unit of work at the same time.

How would you structure/branch the repository

BR,

Rafal

[Former Member]

Hi Rafal,

I think you partially answered yourself. DEV, TEST and PROD are meant to be maintained by branches in repository. You are right about that. Releases can be maintained as versions in individual branches. You can use standard (incremental) versions or more "independent" baseline versions. It is more common, that there for example 30 versions in DEV environment and only a few versions in PROD environment. These few versions correspond to the number of releases on production.

With logical units of work it is more complicated. The correct decision depends on more factors. One of them is, whether they run in parallel or serial mode. Another is the information, whether the customer uses the repository for daily sharing the models among users or only for storing the models when some portion of work is done (and users keep the models locally or on shared network drive). If the repository is being used daily, then these logical teams can work in parallel (and see each others modifications) and must be able to perform check-in operation correctly. This can be issue because check-in (and merge) must be done by someone, who is able to resolve potential conflicts on objects. For the second case (models kept locally for longer time, or models shared on network drive for daily access), I have developed an extension, allowing users and teams to LOCK INDIVIDUAL OBJECTS, allowing even big teams of users to work in parallel WITHOUT ANY CONFLICT on main in the models during the final check-in/merge. You can contact me privately if you are interested in this topic more.

I really don`t think, that solution for this parallel units of work should be resolved by creating duplicit copies of the same model for different teams. It would be necessary to merge these copies before releasing and also postponing the "meeting" of changes from different copies would dramatically increase the risk of potential incompatibility of these modifications.

I hope that this short summary will help and in case you are more interested in some these ideas, you can contact me privately.

Regards,

Ondrej