[evs] Branching on commit, merge documentation

Arthur Barrett arthur.barrett at march-hare.com
Wed Sep 12 14:23:02 BST 2007

Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.


> So, if I understand that correctly, instead of keeping several parallel
> branches (e.g. one for the 3333 development and another one for 3336), you
> keep several parallel sandboxes (one where the 3333 development happens 
> and
> one where the 3336 development happens).

Yes - that's standard unreserved / distributed versioning - what all CVS 
users do (only CVSNT supports alternatives like centralised unreserved 

> With this update, the final commit under this bugid now contains code
> merged in from other bugids. For example, a final commit on 3333 may
> contain a halfway done (and not yet working) implementation of the code 
> for
> the new board on 3336 (that works neither on the old nor on the new 
> board).

Yes I pointed out that 3333 and 3336 probably are dependant.  The only way 
to fix that is with a reserved process (or refactoring the code).  I suppose 
you could keep a parallel branch (dev_twinkie_2?) but you'd only perform one 
merge, down, to dev_twinkie when it is complete and then handle "fixes" 
thrown up in testing from there...  But really if you cannot live with 3333 
and 3336 becoming dependent then refactoring the code or using a reserved 
process is the only way to go.

> I think that this has the potential to introduce all kinds of strange and
> difficult to find bugs, because you don't really know what you're merging
> when running the promotion merges -- unless your bugid commits are all a
> single block. Which they usually won't be if all features/bugs are being
> developed/fixed on dev_twinkie and developers commit regularly. That
> promotion merge will bring in any amount of code that has been developed
> and committed independently of 3333, and that also may not be yet complete
> or even working.

Ahh - but the other smaller changes do naturally tend to be much more 
atomic.  No CM system or process I've seen can handle several large 
independent changes that affect the same files as each other occuring 
simultaneously with regular "progress" commits and still keep the changes 
separate.  The "solution" then is always refactoring.  It is not a well 
documented relationship between CM processes and code design, but I've 
discussed this with several CM professionals and they all agree that the 
relationship is there, and in situations like this that is the only place it 
can be fixed*.

> Only if their commits actually were "atomic" in the sense that there were
> no intermediate commits on other bugids.

Again - it doesn't work like that in practice.  Usually the change is 
atomic, and if it is not then the code wont unit test or perhaps it wont 
even compile, in which case the developer of the smaller piece of code fixes 
the problem (by rolling out the previous - unwanted - commit).

> In my work, this is a very common scenario. It is not always possible to
> architect the application according to the needs of the VCS. In general, I
> tend to think that the VCS should support the architecture, which in turn
> should reflect the project requirements. The VCS is for me not a project
> requirement, it is a tool to achieve them.

It's a catch 22.  It's not really a fault in the tool* it's a limitation of 
modern CM best practice - the code must be manageable to be managed.  There 
are some brilliant programmers out there that will never get high paying 
work - not for lack of talent, but because they are "unmanagable" - and it's 
the same with code - it's not good enough that it works, it must be 
"manageable"...  However as you've described your code and process I do not 
think it's the case.  I agree, it's easy to look at the theory and poke a 
lot of holes in it, but if you give it a go you will find it works in 
practice.  I can poke (the same?) holes in your current workflow, but that 
works...  Chaos theory...

> I'm not sure what you call a reserved process. If you mean file locking,
> that doesn't work -- I can't lock all files that are affected by the new
> board while the board goes through the testing and pre-production phases.

It's not file locking because it only affects the branch you are working 
on - it's better known as "reserving".  And no - you don't normally keep it 
reserved after development/unit test has completed - however you then get 
into project management...

> That's why we do this on a branch. The branch permits me to make sure I
> only merge features that are complete and at least tested and "released" 
> by
> the developer. This is something bugids alone don't ensure -- as Tony
> explained. You seem to be using separation of code into files as an
> additional tool to manage conflicting commits (in the sense you suggested
> with the partitioning of the application); I think that branches are a 
> more
> general and less intrusive tool.

Except as has been shown that doesn't work.  After I finished off last time 
I remembered more about the "technical fault" in what you are doing by 
merging "back" - it isn't a merge (because you cannot merge 
bi-directionally) it is a copy/replace and you run the risk of losing 
changes that were not merged in to the branch first.  If you are really 
paranoid you can do as I described above and put 3333 on dev_winkie_1 and 
3336 on dev_twinkie_2, but you only merge them back down into dev_twinkie 
and only once.

Note *: Apparently CM types know this is a problem and have been discussing 
it for years, though it only came to my attention about 18 months ago, and 
much to Tony's regret I passed the info on to him.  The "holy grail" in CM 
now is a tool that will version something smaller than a file (eg: a line, 
or a function).   I think this is the feature you really want and are trying 
to describe.  Once an SCM tool can version something smaller than the entire 
file, then the code can be as monolithic as you want because the SCM system 
understands and tracks not just version 1.18 and 1.19 and and the 
merges, but it knows that this "changeset" is these lines and those lines 
within that file.  This still wouldn't make the SCM system intelligent, 
however it would allow the SCM system to be told to construct a view of the 
project with bug fixes 2 and 3, and also a view of the project with bug 
fixes 2 and 4.  EVS is NOT intended to address this, and unless a LOT of 
people buy (that's purchase the commercial version...) EVS licenses then it 
never will be a project I or Tony consider...  The reason why noone (not 
even IBM/Rational who are widely considered the CM kings) has done it is 
that it's in the seriously difficult bucket (and would require a complete 
re-training of CM professionals)...


Arthur Barrett

More information about the evs mailing list