[dev] Horde 4 Kickoff - Git migration and layout

[Chuck Hagenbuch]

Quoting Thomas Koch <thomas at koch.ro>:

> Yesterday, at 22:53 CET, Chuck proposes a GIT layout and this morning at
> 6:05 CET the decision is already made.

No. An initial structure was put in place, because I have limited time  
and energy and I'm going to try and move forward when I can. There is  
still plenty of time for feedback and improvements. And there is not  
much in git at this point; any reorganization that loses history is  
simply not an issue for the next few weeks probably.

> I'd not use two separate repositories for hatchery and stable. Since
> we're talking DVCS, you can easily have one branch for stable and one
> branch for hatchery in the same repository. You can also easily clean up
> dead branches.

My concern is checkout size. I am _not_ proposing having development  
versions of existing applications in the hatchery; those would be in  
branches in the main repository. The hatchery is for things that are a  
complete mess, still in development, where code is being moved around  
like crazy, maybe files from other languages that are being ported is  
included, etc. In order to allow tossing things into version control  
without worrying about the main repository size, such things would go  
in the hatchery.

> Having two disconnected repositories makes it only harder to merge new
> components in or to get updates from stable.

The only path here would be moving a project from the hatchery into  
the main repository. Is there not a way to pull a directory in this  
fashion?

> Instead I'd have one repository for the framework/library and another
> one for the horde applications build on top of the framework. This
> implies the philosophy, that the framework should be useable for other
> projects too and that other projects should be encouraged to participate
> in the using and development of the framework.

Doesn't this have the same problem of having two disconnected  
repositories? Just because the framework is intended for use beyond  
Horde, it's still central to Horde, and making it more difficult to  
work on both the framework and horde applications seems  
counterproductive to me.

-chuck