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

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> 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.

This is sounding good to me.

>> 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.

I'm not really in position to be doing a ton here, but for branches,  
at least the Vfs stuff I started I'd like to be in a separate branch,  
not in a generic h4-refactoring one. I think in general it'll make for  
easier merging if we use separate branches for each library refactor  
also. That way we can merge eacn individual branch/library when  
they're ready.

-chuck