Timeline for How to achieve a smooth transition from “the one big VCS repository for all products” organisation model to the “many small VCS repositories” model?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 31, 2019 at 18:32 | history | edited | 030 | edited tags | |
| Mar 5, 2017 at 23:00 | answer | added | ᴳᵁᴵᴰᴼ | timeline score: 9 | |
| Mar 3, 2017 at 14:15 | review | Close votes | |||
| Mar 4, 2017 at 1:33 | |||||
| Mar 3, 2017 at 13:49 | comment | added | Tensibai | I think your 6th bullet with git-bisect is missing something. I wonder if this should not be split into separate questions as it's more or less asking for a book. As the definition of a product is highly subjective (and may vary) I think it's actually a little to high level for a question on a SE site. Either too-broad or too opinion based. | |
| Mar 3, 2017 at 5:32 | comment | added | Dan Cornilescu | Things can get a bit more complicated if the products share (platform/product independent) code. Or if there is common code per family of products. Not that splitting would not be a good idea, only management of the parts and the list of advantages and disadvantages would be somehow different. | |
| Mar 3, 2017 at 4:38 | comment | added | Jiri Klouda | We are actually looking into a very similar problem right now at work. The approach we are considering is to have a master repository with no code committed to it and other repositories attached as submodules. But we still need to figure the right tooling and integration of the process to get it done. I will compose a detailed answer when we figure out the details. | |
| Mar 3, 2017 at 4:36 | comment | added | Jiri Klouda | A lot of the problems with single repository are issue with the poor design in modern VCS. Some companies have their internal VCS solutions that are scalable, but nothing that would be public so far. | |
| Mar 1, 2017 at 14:23 | comment | added | Michaël Le Barbier | It definitely is. :) | |
| Mar 1, 2017 at 14:21 | comment | added | Assaf Lavie | A key part of such a solution is a decent artifact repository (e.g. artifactory), which lets you decouple dependent components from the same repo. IOW instead of sharing code (one repo), publish and consume built libraries (artifacts). It's also a good place to start such an effort, because you can refactor/extract your modules one by one. | |
| Mar 1, 2017 at 13:38 | review | First posts | |||
| Mar 1, 2017 at 19:30 | |||||
| Mar 1, 2017 at 13:37 | history | asked | Michaël Le Barbier | CC BY-SA 3.0 |