Handling multiple parallel versions.

Handling multiple parallel versions.

[Ian Hobson]

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

Re: Handling multiple parallel versions.

[Jonathan Nieder]

Hi Ian,

Ian Hobson wrote:

> 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 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

Re: Handling multiple parallel versions.

[Jonathan Nieder]

Ian Hobson wrote:

> So this solution is NOT working for maintaining parallel versions.
[...]
> re-applying the differences between each version (they are a set
> of images and a config file).

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