[dev] Horde 5?

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>>> These fixes were all bugfixes, but they didn't apply correctly to  
>>> IMP 5.0.  And since I no longer run IMP 5.0, I would have never  
>>> caught these issues save for the fact that one of my clients was  
>>> noticing problems.  That was a fortunate occurrence, not the norm.
>>
>> Like I already mentioned in the earlier thread, you wouldn't have  
>> had those conflicts if you had correctly fixed bugs in master and  
>> then had them merged into develop with the regular merging. You  
>> might still have to adapt the fixes to the develop branch, but 1)  
>> you always have to adapt fixes anyway as soon as branches diverge  
>> and 2) you wouldn't have broken the stable master branch, just the  
>> development branch.
>
> This is what I don't agree with though.  In my particular case, I  
> was doing all development work in develop since I thought the code  
> was going to be an improvement, not a bugfix.  But during the course  
> of doing this work in the develop branch, I discovered a bunch of  
> issues with the code as existing in the master branch.   
> Architecturally, things have changed so much that the back porting  
> was annoying, and then the issue becomes when you merge back into  
> the develop branch, things get even MORE broken and you run the risk  
> of losing the original work when resolving the conflicts.  Maybe my  
> brain is slow, but conflict resolution can be very confusing, so  
> errors might slip through.

Agreed, as soon as you start getting conflicts, things get messy. Even  
more so if you end up merging back and forth. But that doesn't have  
anything to do on which branch you do the development.

> And it's always been the case (when using CVS) that we would  
> implement things in HEAD, check that they were stable, and then  
> merge back to the stable branch.  Not sure why you are saying that  
> is incorrect practice now.

We're still doing the same, just the branch names have changed. The  
difference is that merging the development branch into the stable  
branch was a major PITA with CVS and had cost me a complete day each  
time.

> So maybe this is less an issue with repo setup than it was with our  
> (incorrect, IMHO) decision to have the development work proceed on a  
> topic branch.  What we should have done is branched the stable, H4.0  
> branch and had development work performed on master.  Semantically,  
> this makes the most sense: master is equivalent to CVS HEAD and is  
> the most up-to-date, bleeding-edge version of the code.

There is no difference. You start with a single code base. Then you  
branch into a stable (master/FRAMEWORK_3) and a development branch  
(develop/HEAD). Fixes are applied to both branches, new development  
only happens in the development branch. When the next major release is  
due, the development branch gets merged back into the stable branch.

It doesn't matter if the stable branch is named master or develop or  
anything else. It's just wording. There have been several problems  
with the way we (or anybody else) developed with CVS though, so using  
that as a good example doesn't work for me.
- Merging fixes between branches was a pain. It was the equivalent of  
cherry-picking in Git, but without *any* help from the VCS, no  
automation, just manual work, lots of conflicts when merging back, and  
no help with resolving those conflicts either.
- As a result, the longer the development process lasts, people kept  
ignoring the stable branch because it was such a pain, bug fixes got  
lost, i.e. had only been applied to HEAD etc.

With Git, we don't cherry-pick, and even if we do, Git tracks that so  
that merging at a later time doesn't cause conflicts.
Instead we merge the complete stable branch into the development  
branch regularly. The big difference is, that you can now fix  
conflicts in time, close to the original implementation. This is what  
causes your problems if already merged something in the other  
direction (which you shouldn't, but which cannot always be avoided).  
If we didn't do that, it would be *me* that would have to resolve  
*all* conflicts when I merge develop back into master for the next  
major release. And if I misunderstand you and you do *not* want to  
refrain from constantly merging the stable branch into the development  
branch, then I can only repeat what I said above. It's just a matter  
of names.
The situation you described above, and that I fully understand, cannot  
be avoided by simply switching the master and develop branch.

Jan.

-- 
The Horde Project
http://www.horde.org/