Flexible vs static branching (Git vs Clearcase/Accurev)

Question

My question is about the way in which Git handles branches: whenever you branch from a commit, this branch won’t ever receive changes from the parent branch unless you f

Answer 1

I'll try to answer you question. (I have to say here that I have not used GIT only read about it, so if something that I mention below is wrong, please correct me)

"Can you enumerate scenarios where this inheritance is a must?"

I won't say it is a must, because you can solve a problem with the tool you have, and might be a valid solution for your environment. I guess it is more a matter of the processes than the tool itself. Making sure your process is coherent and also allows you to go back in time to reproduce any intermediate step/state is the goal, and the plus is that the tool let you run you your process and SCMP as painless as possible

The one scenario I can see it is handy to have this 'inheritance' behavior and use the power of the config spec, is when you want your set of changes "isolated" mapped to a task (devtask, CR, SR, or whatever defines the purpose/scope of your change set)

Using this composition allows you to have your development branch clean and still use different combination (using composition) of the rest of the code, and still have only what is relevant for the task isolated in a branch during the whole life cycle of the task, just until the integration phase.

Being purist having to commit/merge/rebase just to have a "defined starting point" , I guess it would 'pollute' your branch and you will end up with your changes + others changes in your branch/change set.

When/Where this isolation is useful? The points bellow might only make sense on the context of companies pursuing CMM and some ISO certifications, and might be of no interest for other kind of companies or OSS

• Being really picky, you might want to accurately count the lines of code (added/modified/deleted) of the change set corresponding to a single developer, later used as one input for code and effort estimations.

• It can be easier to review the code at different stages, having just your code in a single branch (not glued with other changes)

On big projects with several teams and +500 developers actively working concurrently on the same base code, (where graphical individual element version trees looks like a messy tangled web with several loadlines, one for each big customer, or one for each technology ) large config specs using composition of several degrees in depth made this amount of people work seamlessly to adapt the same product/system (base code) to different purposes. Using this config spec, dynamically gave each team or sub team, a different view to what they need and from where they need to branch of, (cascading on several cases) without the need of creating intermediate integration branches, or constantly merging and rebasing all the bits that you need to start with. Code from the same task/purpose was branching of different labels but made sense. (You can argue here the 'known baseline' as a principle of the SCM but simple labels contemplated in a written SCM Plan did the work) It must be possible to solve this with GIT (I guess in a non dynamic way) but I find really hard to picture without this 'inheritance' behavior. I guess the point mentioned by VonC "if branched, all its files will branch from the same unique starting point" was broken here, but beside it was well documented on the SCMP, I remember there were strong business reason to do it that way.

Yes building these config specs that I mentioned above was not free, in the beginning there where 4-5 well paid people behind the SCM but were later reduced by automated scripts that asked you what you want on terms of labels/branches/features and will write the CS for you.

The reproducibility here was achieved by just saving the Config Spec along with the task in the devTask system, so each task upstream mapped to requirements, and downstream mapped to a config spec, an a set of changes (code files, design documents, test documents etc)

So up to here one conclusion here might be, only if your project is big/complicated enough (and you can afford SC Managers along the life of the project:) ) then you only will start thinking if you need the 'inheritance' behavior or really versatile tool, otherwise you will go directly to a a tool that is free and already take care of the coherence of you SCM ... but there could be other factors on the SCM tool that might make you stick to one or to another ...read on..

Some side notes, that might be out of topic, but I guess in some cases like mine need to be considered.

I have to add here that we use the "good-ol CC" not UCM. Totally agree with VonC on the a good methodology allows to "guide" the flexibility towards a more coherent configuration. The good thing is that CC is pretty flexible and you can find (not without some effort) a good way to have thing coherent while in other SCM you might have it for free. But for example here (and other places that I've worked with CC) for C/C++ projects we cannot afford the price of not having the winkin feature (reusing the Derive objects), that reduce several X times compiling time. It can be argued that having a better design , a more decoupled code, and optimizing Makefiles can reduce the need to compile the whole thing, but there are cases that you need to compile the whole beast many times a day, and sharing the DO saves heaps of time/money. Where I'm now we try to use as much free tool as we can, and I think we will get rid of CC if we can find a cheaper or free tool that implements the winkin feature.

I'll finish with something that Paul mention , different tools are better that other for different purposes but I will add that you can get away from some limitation of the tool by having a coherent process and without scarifying reproducibility, key points off the SCM In the end I guess the answer to it is worth? depends on your "problem", the SDLC you are running, your SCM processes, and if there is any extra feature (like winkin) that might be useful in your environment.

my 2 cents