[dev] The layout of the git repositories

[Michael Rubinsky]

Quoting Gunnar Wrobel <p at rdus.de>:

> Hi!
>
> For Horde 4 three git repositories ("horde", "horde-hatchery", and  
> "horde-support") have been created. All of these seem to be intended  
> as central source repositories where the developers push commits to.
>
> I am by no means an expert in revision control systems but this  
> seems to be a very uncommon setup for a distributed revision control  
> system. In a distributed system each developer usually has his own  
> branch(es) and people do pulls rather than pushes.
>
> Is there a specific reason why this approach of a central repository  
> has been chosen?
>
> This is connected to the fact that the different horde modules are  
> being stored within one big repository rather than storing them in  
> separate repositories. Git does not support partial checkouts so a  
> user will always have to checkout the full source tree. As the fact  
> that git does not support partial checkouts is definitely not a  
> defect in its design I tend to question the current module layout in  
> the new repository.
>
> When using distributed developer branches you'd assign maintainers  
> for each of the available modules. These maintainers are responsible  
> for releases of the modules they manage and usually pull from the  
> people they trust. This will not work if all modules exist within  
> one repository as you would need to care for things beside the  
> modules you maintain.
>
> The current setup gives me the impression as if we were coming from  
> CVS - which we did ;) - and wanted to keep the logic behind CVS. But  
> of course distributed revision control is pretty far away from CVS  
> and uses some radically different concepts. And it feels strange if  
> we try to use git for something it was definitely not meant to be  
> used for.
>
> But maybe I'm exaggerating and there are some good reasons for the  
> current setup. Maybe somebody can give me a hint.
>
> Cheers,
>
> Gunnar
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> --
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>

To add my personal opinion here -

In my mind, with our current workflow the "shared repository" model  
works very well.  We don't have any one "super user" to have to review  
and approve any commits from the core developers. IMO, having a master  
maintainer for each module would be much more work, and possibly even  
more confusing. I don't think we have the developer resources to  
properly manage that.  If someone with commit access wants to  
coordinate development on some feature with someone who does not, I  
can see pulling from the other developer's repository, reviewing, then  
pushing to our repository....but I'd be against having to have a  
single maintainer having to pull from me when ever I had changes  
ready.  I also don't want to have to worry about maintaining a  
public-facing repository somewhere where this maintainer could pull  
from.

As far as all the modules under one repository - yes, anyone working  
on development would need to clone the entire repository, but that  
would only have to be once, since each checkout *is* a repository. I  
feel that it is easier to manage with everything in one (well,  
actually three) checkouts.  Of course, with the state our source code  
is currently is - split between CVS and Git - the 'easier to manage'  
point might be lost :)

I'm not so sure that we're using "git for something it was definitely  
not meant to be used for" - the Git docs explain how Git can fit in  
with the 'shared repository model' as one method of collaborative  
development for those projects that it makes sense for.

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin