eZ Community » Forums » Developer » How do you organize your eZ Publish...
expandshrink

How do you organize your eZ Publish extensions in GitHub?

How do you organize your eZ Publish extensions in GitHub?

Thursday 15 March 2012 11:13:47 am - 6 replies

Hi,

We are currently hosting all our projects on SVN (at BeanStalk) but are considering taking the plunge and moving to GitHub. However, GitHub doesn't really seem to make a good fit for an average eZ developing company. I'll give an example of what I mean.

Currently we one repository for general purpose extensions, and one for site specific extensions. Both hold some 100 extensions each. This works fine because we can easily check out a subfolder of each repository (the specific extension) into the extension folder of a given site.

However, as I've come to understand, Git doesn't support this kind of behaviour very well. Allthough it has supported "sparse checkouts" since version 1.7, using this method doesn't really allow for rewriting the structure of the checkout, which means we're back to square one.

We could, of course, put all these extensions into separate Git repositories, but since a lot of them are client specific (and hence, private) it wouldn't scale well with GitHubs price model for private repositories.

So my question is this:

Are there any other eZ developers out there using GitHub as their sole VCS platform, and if so, how have you set it up?

Thanks in advance!

Wednesday 21 March 2012 12:24:50 pm

Hi Eirik, 

Although I have not implemented this technique (yet), I have heard about git sub-modules quite a lot. An investigation track ?

Cheers,

Wednesday 21 March 2012 2:17:30 pm

Hi Nicolas,

Thanks for replying.

From what I can gather from http://help.github.com/submodules/, submodules seems to be more of a way of pulling in external repositories, and would hence require a separate repository for each submodule. This is of course what I'm hoping to avoid.

Wednesday 21 March 2012 2:26:47 pm

Hei, 

Ok I see. May the crowd help.

Cheers !

Sunday 25 March 2012 8:20:18 pm

For anyone else that might be interested (and allthough not exactly what I was looking for), I just discovered BitBucket.org which provides an unlimited number of private repositories, and rather charges by user count.

Allthough this (seemingly) fixes the pricing issue, we're still left with an organizational problem with regards to a good way of organizing repositories in a one-level structure. There is a BitBucket issue reported to remedy this (https://bitbucket.org/site/master/issue/2323/create-folders-to-organize-the-repository), but it's unclear whether the BB team has any plans to implement this in the near future. 

Monday 27 August 2012 12:37:57 pm

hello. I reopen this post as i was working in something similar last weekend.

Following this piece of code https://gist.github.com/704810

i came to a solution where, in this case, ezcommunity project is included in your custom project as a submodule.

Then, a symlink is added to every folder in ezcommunity build except those in which you may be adding your custom code. at first, i thought only in settings and extension folder.

Just for testing purpouses i created a dummy repo here http://github.com/crevillo/ezb.git

and another one in http://github.com/crevillo/ezc.git, which will track all the ezcommunity builds in the future.

but, regarding your question, as far i know, problem with git submodules is you cannot point a submodule to a subfolder of another repo. you can only point to the "root" of another repo, so don't know if my (not really well tested yet) solution can help you with this...

Cheers

Sunday 02 September 2012 12:34:18 pm

I commented about this last year, as I was running into the same issues & decisions, and while I have used Subtree Merges, using Submodules is a lot easier (and the same as tagged/revisioned SVN externals).

BitBucket sounds like a much better option for agencies, given the unlimited repos & the nature of working with Git.  It seems neither GitHub or BB have resolved how to allow users to organize their repositories better, but there's no reason you couldn't simply use a naming structure for your repos which reflects the structure/organization you want, as an interim measure, e.g <client>-<extension>.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from