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

[Michael Rubinsky]

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.

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.




Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin