[dev] Horde 5?

[Gunnar Wrobel]

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

> Quoting Gunnar Wrobel <wrobel at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting Ralf Lang <lang at b1-systems.de>:
>>>
>>>>>> I think we began changing the Wiki page to "Horde 4.1 not planned"
>>>>>> before it went into maint.
>>>>>
>>>>> I would love to start breaking BC and removing deprecated stuff, since
>>>>> it seemed like half of the work/fixes I did this evening was figuring
>>>>> out how to keep compatibility rather than fixing the problem.
>>>>>
>>>>> But I also think before we start work on Horde 5 we should probably
>>>>> decide on how (or if) to setup the git repo differently than what we
>>>>> currently have. Meaning: separate git repos for each
>>>>> application/framework going forward?
>>>>
>>>> Don't know if we shouldn't postpone this repo reorg to release time.
>>>
>>> I would vehemently disagree with this statement.  The time to  
>>> change repo structure must occur during the developmental window,  
>>> not right after the first stable version is released.  What if we  
>>> discover that we can't accommodate a new structure under Horde 5,  
>>> as released?
>>
>> We'd stick to the monolithic repository for Horde 5 then and would  
>> prepare Horde 6 in the splitted repository.
>>
>> Question is: Are there issues to be expected that will bite us  
>> later in case we go with a monolithic repo for the switch from  
>> Horde 4 to Horde 5?
>
> The major issue wouldn't bite us immediately, but it would affect  
> when we start doing Horde 6 development and start merging fixes back  
> into Horde 5.  This is the problem I recently ran into, and it broke  
> a bunch of stuff in IMP 5 due to major issues with a merge.
>
> 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.
>
> And the reverse is true also.  I just noticed that the Edit As New  
> menu item I added to IMP 5.0 a few days ago got lost in 5.1 due to a  
> double conflict in a merge (e.g. stuff was merged from 5.1 -> 5.0,  
> this merge needed to be edited to work in 5.0, then when 5.0 was  
> merged back into 5.1 this commit got lost).

At first sight this sounds like a pure git problem however. Especially  
the "Edit As New" commit: This is restricted to the IMP component  
anyway. Would splitting the repo into single components help here? I  
would assume such conflicts could happen in just the same way?

I know I still lack deeper insight in the more complex git merge  
techniques. SVN obviously fails at cyclic merging which I have the joy  
to experience weekly at the moment. But I assumed this is less  
problematic in git.

Cheers,

Gunnar

>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de