threads / discuss / 26967

Git enterprise setup on a large project

Subject: Git enterprise setup on a large project

## tl;dr

2 messages between Apr 2, 2011 and Apr 3, 2011.

replies: 1people: 2as markdown or json

Frederic JECKER· Apr 2, 2011, 19:50 UTC · lore
Hi,

I'm looking to replace my team's old and clumsy CVS server, as a GIT user for personal projects I'm wondering what would be the best way to achieve this using GIT. I've googled the subject a few times and read books but I still have a handfull of questions

Our team is composed of 10 developers. A common developer workspace takes about 1Go of space and contains about 50 modules (up to 100 if the developer is working on satellite applications/modules) - we're maintaining a large java-based healthcare system. Each module is a CVS project. Our use of CVS is.. well..clumsy too (don't ask me why we do things like this, those were decided about 10 years ago before I started working in this company). Features to be delivered in the next release are committed directly on the head. The project leader cherry picks the commits on his local working copy within a dedicated workspace.

I first thought of creating a single project in order to group the 100+ modules and to ease the creation of maintenance branches. Each developer would clone the full workspace from a "blessed" repository. The "blessed" repository would be managed by the project leader which would simply pull changes from each developer pubic repository. I tested this scenario but, as the workspace is really big, each operation is really slow.

What could I do then ?
- Use submodules ?
- Create a blessed per-project repository and instead of a public
repository for each developer create a per-project public and shared
repository ?
...I'm a bit lost
Thanks for your help
Fred
Enrico Weigelt· Apr 3, 2011, 18:31 UTC · re: Frederic JECKER · lore

Re: Git enterprise setup on a large project

* Frederic JECKER <frederic.jecker@gmail.com> wrote:
Show 6 quoted lines
> What could I do then ?
> - Use submodules ?
> - Create a blessed per-project repository and instead of a public
> repository for each developer create a per-project public and shared
> repository ?
> ...I'm a bit lost
Just think about who has to see whose commits ?

I guess, each project's codebase is accessed by a relatively small number of people. So it IMHO would be natural to give each project a separate (blessed) repository. The project leader will merge (or cherry-pick) the blessed changes here, and other merge-down or better rebase from there.

If there's some big mainline (the base for many other projects), it should live in its own repository. BTW: you dont have to use full clones - you could also fetch individual refs if you like.

Individual WIP branches probably dont necessarily need to be pushed into the central project repos - devs could sync each other selectively.

cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

← back to recent threads