Multiple repositories - grouping and tools

[LaughingJohn]

Hi,

 

We're currently using Git and I just stumbled across plastic. It looks very interesting. Although we're fairly happy with Git in most respects there is some friction in the way our product and respositories are organised.

 

We have a product that consists of many parts and components. In some cases this is because there are just separate parts for example there is server code and client code. Additionally in our client code we use a kind of plug-in/widget architecture. This means we have many separate solutions (we're using .Net). Currently in Git we have one repo per solution and a corresponding central/server repository for each one. However we'd like to be able to group together the solutions/repos as a "product" and be able to perform operations on the product as a whole whilst still having the flexibility of just working on a single solution if we want. Some of the operations off of the top of my head would be:

 

1. Maintaining a product version whilst also maintaining separate versions for individual components. At the moment we simply have a script that labels all git repositories with an overall product version after a build. This is OK, but there's no simple way to see what version of each component make up a build of the product.

 

2. Pulling and pushing the whole product. Sometimes you just want to grab the latest of everything (especially before a build). Whilst there are several ways of doing this in Git it's not entirely straight forward.

 

3. Having an overall view of the product. It'd be nice to have a view across all repositories (kind of like a root folder) to see what's going on and be able to drill down without constantly swapping between repositories/folders. This would be useful at the remote/local and even local working tree levels. This becomes more helpful when you have multiple products.

 

4. Seeing what's changed across product versions. An overall diff if you will. Also diff the local working tree changes across the whole "product".

 

5. See any local outstanding changes across a product. We often make changes to multiple parts as part of a change set.

 

6. Not grouping per-se but it would be nice to be able to stamp files in some way so that we can see what version of the product and component they were built from.

 

7. Clone the entire product locally.

 

etc. etc....

 

These sort of things are easier in traditional version control systems (as you often had a root directory and the whole thing was centralised) and there some git tools scripts that help a bit. I just wondered whether plastic offered any sort of functionality that would make this kind of thing easier?

 

Regards,

LJ

[manu]

Hi John!

 

1. Maintaining a product version whilst also maintaining separate versions for individual components. At the moment we simply have a script that labels all git repositories with an overall product version after a build. This is OK, but there's no simple way to see what version of each component make up a build of the product.

 

This is why we developed the Xlinks!!

 

Xlinks can link multiple repositories in a single one and you can always go back and rebuild an static configuration as it was in that certain moment, using labels or not this is always possible -> No broken builds or missing/wrong dependencies..

 

For example, down here we have our "codice" master repository that contains links to:

 

* Client code

* Server code

* Third party libraries

* Plugins code

* Testing suite

 

Each of them are independent repositories that evolve as a single product "codice".

Labels are created across xlinks so it's super easy to know and rebuild a past release.

 

2. Pulling and pushing the whole product. Sometimes you just want to grab the latest of everything (especially before a build). Whilst there are several ways of doing this in Git it's not entirely straight forward.

 

Well, Plastic SCM can behave as a central VCS or a distributed VCS, or even a mix of them.

Pushing and pulling information between server is extremely easy using the SyncView.

 

You also have the branch explorer, that has DVCS features so you can see remote changes in your branch explorer and know if you are missing something.

 

 

3. Having an overall view of the product. It'd be nice to have a view across all repositories (kind of like a root folder) to see what's going on and be able to drill down without constantly swapping between repositories/folders. This would be useful at the remote/local and even local working tree levels. This becomes more helpful when you have multiple products.

 

Using xlinks will allow you to have a root repository with a root directory on top of it containing sub directories that will be the xlinked repositories, their content will be downloaded as a single repo.

 

 

4. Seeing what's changed across product versions. An overall diff if you will. Also diff the local working tree changes across the whole "product".

 

If you use xlinks the diff operation will show you the differences of the full tree as it was a single repository (but it's not!    ).

 

5. See any local outstanding changes across a product. We often make changes to multiple parts as part of a change set.

 

I'm not sure about this one.

 

6. Not grouping per-se but it would be nice to be able to stamp files in some way so that we can see what version of the product and component they were built from.

 

I'm afraid we can't change the file content or the timestamps in that way.

 

7. Clone the entire product locally.

 

Plastic is a DVCS so you can always have a local copy of the master repository.

You are not forced to "clone" (we call it replicate) the entire repository, you can choose the branches you are interested in.

[LaughingJohn]

Bit late back, but thanks for the information. Xlinks sounds interesting, I'll have to read about it!

[manu]

Sure! I think they really fit for you.