[dev] Git splitting

[Michael M Slusarz]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> One of the major issues right now, as I see it, is that is is  
>> pretty much impossible for ordinary users to easily create patches.  
>>  We essentially require them to run a completely separate  
>> installation in order to do this.  By changing, we now dramatically  
>> lower the bar for development entry.  People can install and run  
>> their installations through the normal channels (i.e. PEAR), and  
>> then only need to download a tiny subset of Horde (i.e. Horde_Core)  
>> when they discover a bug.
>
> Except that then they can't actually test said patch if they are not  
> running the code they are patching. Of course they can always play  
> with include_path to ensure the git version is included first  
> (assuming they can figure out how to install the libraries properly)  
> but that just opens up a whole other set of problems with  
> dependencies. Not saying we shouldn't split, it's just something  
> else to think about. I don't think this transition is going to be as  
> easy as you are saying it will be for non-horde developers to make  
> use of the split repo.

IMHO, you are way overestimating the effort it would take to do this.

Example:

1. User running their production version of horde from a PEAR install.
2. User discovers Horde_Core issue.
3. User downloads the git repo for Horde_Core anywhere they want on  
their system.
4. User configures autoloading to point to the Horde_Core directory  
they want to use instead of the global Horde_Core  
(horde/config/horde.local.php would be a place to allow this).

Done.  There cannot possibly be an argument that this is more  
difficult than the current process.

Not to mention, I can't wait for this to be the development setup.  I  
just need to download the git repos of the base applications I want to  
work on.  Then I can just do something like install all PEAR libraries  
globally (or, even better, do a composer install of dependencies into  
a local directory).  Then, as I need to work on an individual library,  
I can download it and switch over to using it.  Incremental instead of  
a painful long initial setup.

>> For me, large chunks of version 3 of Horde_Imap_Client have been  
>> written already, and switching to this kind of development will  
>> actually allow that code to see the light of day -- since it is  
>> completely impossible right now to do this with the current setup  
>> (creating a topic branch does NOT work for this kind of thing).
>
> I'm curious why it doesn't work.

I want to work on Horde_Imap_Client version 3.  So I create a topic  
branch.  It is API breaking.  So it breaks IMP.  That is not useful.   
So now I have to essentially write a new version of IMP in that  
branch?  But I just want to change things in Horde_Imap_Client!

Later, I may have to make changes in version 2, which is living in  
master.  These changes should never ever go into version 3.  But at  
some point with a monolithic repository, I will eventually have to  
merge my version 3 changes into master.  But I don't want that!   
Version 3 is a rewrite!  I really don't want to have to figure out  
complex merge conflicts months after I have worked on the code that is  
causing the conflicts.

So to get around this, I instead have to develop version 3 on master  
and do a branch of version 2, where I make fixes and releases.  But  
that won't work because now IMP is broken again.  Aargh!

And initially, I'm thinking version 3 requires a newer version of  
Horde_Mime.  But how does that work?  The answer is absolutely NOT  
"create a separate topic branch for Horde_Mime and continually merge  
it into the topic branch for Horde_Imap_Client".  What does Horde_Mime  
have to do with my changes for Horde_Imap_Client?  They are completely  
independent.  I don't want them on the same branch!  And what if I  
later decide I don't need a new version of Horde_Mime.  How does that  
work?  Backing out all commits touching Horde_Mime is not a valid  
answer.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]