[horde] Using GIT for Horde?

[Chuck Hagenbuch]

Quoting Thomas Koch <thomas at koch.ro>:

> thanks for your openness to new ideas.

You're welcome. :)

> I just repaired my horde GIT repo. I had installed gitweb in the meanwhile,
> but forgot to also put a link to horde there. You can see the output at
> http://git.koch.ro
>
> I'll happily help with setting up GIT for horde. My current configuration is
> one simple script:

Cool, thanks. I'll have to play with this stuff some more - not just  
at the moment unfortunately.

However, here's a question that you or someone else might be able to  
answer that would go a long way towards us being able to migrate to  
GIT for Horde:

With CVS, we can create this structure:
horde/
   imp/
   turba/

... where horde, imp, and turba are all modules checked out from  
cvs.horde.org, where they are technically on the same level, but we've  
put imp and turba inside horde. And CVS will happily update all of  
these for us with a single cvs update command.

It's pretty much impossible to emulate this with svn, which has put a  
wrench in our ideas about migration to it. Can we do this with GIT? If  
so, you might have a convert.

> Remember, that this script runs three days for the initial checkout when the
> CVS repo is not on the same server.

Do you know about how much disk space it ended up taking? I might be  
able to run it on the cvs server if we have the space.

>> including eZComponents for configuration, authentication and
>> mail transport,
>
> 1) In case that there isn't yet a component inside horde, then it's better to
> reuse something existent.

It depends on what that other thing is, and if it fits Horde's  
philosophy. Not to mention how buggy it is, how well updated, what  
license, if Horde developers can contribute to it, if we can  
distribute it or if it's going to be an installation dependency  
that'll make things harder for people using Horde... :)

> As far as I see, the configuration in horde is done with big arrays.

Yup. Hashes are a pretty good pattern in PHP actually. I wouldn't mind  
having some objects around scoping them (i.e. the config arrays  
shouldn't just be in the global scope) and maybe reading/writing them  
to alternate files, but the config array format isn't actually  
something I think we need to change.

Actually, I take that back, but the thing I want to replace it with is  
far more interesting for Horde's purposes (imo of course) than  
ezcConfig:
http://wiki.horde.org/Project/HordePolicy

> 2) One of the major design goals for horde should be loosely coupling as
> strict as possible.

Loose coupling is good, yes, but blanket statements like this make me  
wary - there are always tradeoffs.

> So if I like for any mysterious reason to replace the
> authentication component with ezcAuthentication or Zend_Auth it should be
> possible without major headaches.

Some of that depends on ezcAuth or Zend_Auth, no? If the APIs aren't  
the same, I don't see why Horde should have extra code just to deal  
with that. The way I'd do this is to write a Horde_Auth_zend or  
Horde_Auth_ez subclass, that did the translation, while letting the  
rest of Horde only worry about one API...

> BTW.: If I'd like to make my customized version of horde with some components
> replaced by others, it's much more easy to do so with a distributed VCS.

Can you say why? I'm still trying to "get" GIT. Thanks. :)

-chuck