On 3/6/19 8:18 AM, Sean P. DeNigris wrote:
Tim Mackinnon wrote
how is this shared repository supposed to work? While I initially liked the space efficiency of the shared approach, I eventually gave up because it created too many (often obscure) problems. It just doesn't seem to be a good match for git, although you can get away with it in the simplest cases (read-only, no branch switching).
The use case that I have used for years (tODE and GemStone) is that I am sharing 60+ git repositories amongst 60+ images and I want all of the images to be sharing the same versions of all of the git projects. When I want to do private work I create a clone that is local to the image that I'm working in and do my work on a topic branch ... when I'm done with the private work, I merge the topic branch back into my commonly shared branch and then update the shared git repository so that when I do activate one of the images. I can quickly tell (via tools) that i have not loaded the latest shared code into my image ... if I care (like preparing to do development), I update to the latest shared code, so that my changes can be shared... if I don't care, then I remember not to make any code changes that I want to keep:) The images that I am using are a mix different versions of GemStone, so I _do_ make it a practice to ensure that projects I work with are all loadable in the different versions of GemStone that I care about via baseline changes (I use packages for version-specific code and avoid putting version-specific code on different branches or tags) ... So, when you say it's not "a good match for git", I don't think that it is "git" that is the problem, but the use cases themselves are the culprit... different tool features are very likely needed to support different use cases ... Dale