[dev] [commits] Horde-Hatchery branch master updated. d3fcd5cdd11ada51d44c03fccd529ba9beed543d

[Jan Schneider]

Zitat von Michael Rubinsky <mrubinsk at horde.org>:

>
> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>>
>>> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>>>
>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>
>>>>> The branch "master" has been updated.
>>>>> The following is a summary of the commits.
>>>>>
>>>>> from: da4c5687690883de5668a2ce8bb7b279a815b6d1
>>>>>
>>>>> 35c0f39 Move imp to horde-git
>>>>
>>>> Should we maybe rename the apps that have moved out of hatchery  
>>>> instead of removing them, at least until we can use Chora to  
>>>> browse history of deleted files?  I get nervous when we can't  
>>>> browse history...
>>>
>>> What about tagging or branching the apps we want to move, adding  
>>> horde-hatchery as a remote to horde, and merging the branch in?  
>>> That should pull everything for those apps into the main repo.
>>>
>>> If we want to revisit having multiple repos, I'm also open to that  
>>> at this point. Git seems to scale just fine; honestly at this  
>>> point I would probably lean towards having one repo for apps, one  
>>> for the base package (whatever that ends up looking like), and one  
>>> for the framework - plus the supporting ones like hordeweb.
>>
>> That distinction doesn't make more sense to me than the distinction  
>> we currently have. I'm teared because I agree that a single repo  
>> for all apps  would work as well as the current solution with two  
>> repos. But checking out a single application is a PITA in both cases.
>
> I think it makes sense to have a single repo for the apps and a  
> seperate repo for the framework. Though I'd probably vote for  
> putting the base package in the same repo with the apps. As far as  
> single apps being a PITA, I agree, but for people that really only  
> want the bleeding edge source for one or two apps, we have the  
> snapshots.

If we go down this route, I agree that having the base horde app with  
the other apps makes more sense. A separate repository for all  
framework packages on the top level has its merits too, especially if  
we want to encourage using them as individual components, separately  
from the whole framework.

> Related to another thread we've been discussing, with whatever  
> method we choose for combining our repos going forward, we have to  
> consider how to handle existing framework packages that are  
> currently being rewritten for H4 and are not complete enough for  
> use.  For people like me that are using case insensitive file  
> systems, this is causing conflicts. For example, the H3 package of  
> VFS was imported into hatchery, but it conflicts with the H4  
> Horde_Vfs package that was already there. This causes issues with  
> Git due to the differing case and (to a lesser extent) untracked  
> files polluting the Vfs directory. This will also cause conflits  
> when a package.xml file is added for the H4 package. In the short  
> term, we could export the H4 packages into horde-git and keep the H3  
> packages in hatchery, but this really doesn't feel right either  
> since Vfs (and iCalendar, and probably a few others) are not really  
> ready for use.

Only the ones that have conflicting names are really an issue. For Vfs  
I already proposed a solution. For others we could add the H4 code  
into a branch ("h4-refactoring" or some such) and keep the H3 versions  
in master for the time being.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/