Handling multiple parallel versions.

Hi All,

I need your advice.  I started with the "Rebase master" approach.

Now I have...

O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O  Master
| \
|  O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O London
|
| \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Birmingham
|
| \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Glasgow
|
| \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Sheffield
|
  \ O--O--O--O--O--O--O--many more--O--O--O--O--O--O--O--O Cardiff

All the rebase master's are taking an age (and involve many conflicts). They are taking linger than the development.

So this solution is NOT working for maintaining parallel versions.

I can get to.

O  Master
| \
|  O   London
|\
|  O  Birmingham
etc

by re-applying the differences between each version (they are a set of images and a config file).

Then I am left with the main problem that I need help with.

When I have done some development and I have

O--A--B  Master
| \
|  O   London
|\
|  O  Birmingham
etc

how do I get to the following?

O--A--B  Master
            | \
            |  B''   London
            |\
            |  B'''  Birmingham
              etc

Answers gratefully received.

Regards

Ian

Hi Ian,

Ian Hobson wrote:

I like the train track guide. My suggestion would be to take a step back and consider what your requirements are.

‘git rebase’ was designed to support a workflow in which individuals are responsible for short patch series (up to 10 patches, say) that have not been reviewed and accepted yet. To save reviewers the trouble of placing themselves in a mindset of the past, the patch submitter occasionally “refreshes” the patches to fit an appropriately modern codebase.

With this comes a downside: if the patch submitter immediately sends the patches after doing this (bad submitter!), they are sending untested code. Furthermore, they make it very hard for /other people/ to develop code on top of their constantly shifting code. So when a patch series grows long enough that a simple read-through would be unfeasible anyway, rebasing can be a very bad idea.

You may also be interested in http://thread.gmane.org/gmane.comp.video.dri.devel/34739/focus=34744

Good luck, Jonathan

Ian Hobson wrote:

[...]

Okay, now that I’ve gotten that rebasing rant out of my system:

I suspect the best thing would be to track the branding and configuration file separately from the main source tree. See

http://thread.gmane.org/gmane.comp.version-control.git/146084/focus=146097

for hints.

(sorry for the noise) Jonathan