[dev] Git reorganization

[Michael M Slusarz]

Quoting wrobel at pardus.de:

> I did not pursue that option any further. But my conclusion from the  
> attempts I made was that this approach is somewhat too complex. The  
> initial subtree split takes ages and it feels wrong to have the same  
> code in two separate places. The only argument in favor of git  
> subtree - as far as I can remember - was the fact that having a  
> monolithic repo allows quick installation of Horde from git.

FWIW, we need to use git filter-branch to do the initial subtree split  
in the repo split method.  But it doesn't seem like an overly large  
concern.

Played around a bit today with, for example, splitting out imp.  IMP  
has 7500+ commits, and on my reasonable fast server this took about 5  
minutes (along with stripping out non-IMP tags).  This can probably be  
scripted and the entire Horde tree shouldn't take more than an hour.

> And the last time I chatted with Nils about composer it didn't have  
> support for the installation of web assets - so for Horde the result  
> would be a mixture of using composer and PEAR package definitions. I  
> have no clue how much work it would be to get composer on par with  
> PEAR in that area. Nils suggested that this should not be too hard.  
> But the components helper we have should also be capable of managing  
> PEAR and composer package definitions in parallel.

I would assume we would do something like maintain package.xml files  
and then use the components script to create a composer.json file.  We  
could probably leverage this code:

https://github.com/claylo/conductor

BTW, adding yet another advantage to separate repositories: this  
greatly simplifies/improves continuous integration reporting.  Not  
only does this drastically take the time to check a commit, it more  
directly targets the actual changes the commit made.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]