[dev] Git splitting

Fri Jun 21 23:31:16 UTC 2013

Quoting Michael M Slusarz <slusarz at horde.org>:

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

This isn't much different that having them add 2 lines to  
registry.local.php to get our current git checkout to work locally  
either, but that's neither here nor there.

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

IMHO, you are overestimating the effort of installing the full  
repository. It's hardly "painful" :)

If you, a core horde developer, have a development environment anyway,  
why wouldn't you want to have the latest git code on hand instead of  
having to switch contexts, so to speak, to mess with cloning another  
git repository and messing with include_paths, autoloader config or  
whatever? If I'm tracing a bug down through multiple libraries I'd  
rather have the entire git codebase at hand to be sure that (1) I'm  
looking at the most recent git code - don't want to fix a bug that is  
already fixed since I don't know which library the error is in yet,  
and (2) When I do find a problem that isn't already fixed, I don't  
want to stop, clone the git repo, switch to the git version of that  
library, and then fix it there.

But I digress, this is getting a bit off of the original topic. This  
is simply how you work vs. how I work. Whatever works, to each his own.

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

No, you create IMP_7_0 and do it on that branch. I'm assuming IMP  
would need to be, at some point, refactored to work with version 3  
anyway, right?

To run them together, you create a local branch and merge the other  
two branches into it. Depending on the level of code changes, you can  
even make the commits on this branch and cherry pick them into the  
correct branch when ready. This is what I did with 5.1. Most of the  
time I worked on a local "consolidated" 5.1 branch and cherry-picked  
the commits into the correct upstream topic branch. For larger  
changes, I worked directly in the appropriate branch. I kept different  
local branches with different combinations of 5_0 and 5_1 code to  
ensure BC. With a small shell script this was not much extra work.

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

Agreed, but it isn't any different with a split repo. Each repo will  
still have multiple branches that need to be merged when major, or  
even minor, versions are released.

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

Nothing. You keep them separate and merge the topic branches into a  
local "consolidation" branch.

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

You simply then drop the new Horde_Mime branch, and only merge the  
needed branches into the local consolidation branch.

Anyway, since we are moving to split the repo regardless, I've taken  
up way too much time making these points. We'll all find our new flow  
that works for us. :)

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/dev/attachments/20130621/08b36998/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20130621/08b36998/attachment-0003.bin>