¿Qué estructura de directorys tiene sentido para DVCS como git?

A lo que estoy acostumbrado:

Archivos en los serveres (NY, IN, NC)
En mi máquina de desarrollo:
- Un directory llamado ~ / work
- Subdirectorys llamados ~ / work / NY / devproject, ~ / work / NC / project, etc.
- No pocas veces, subdirectorys llamados ~ / work / NY / release / 1.3 / project, ~ / work / NY / test / 1.3b / project etc.
- A veces directorys llamados ~ / proxy / NY, ~ / proxy / NC, etc. que contienen un caching local desechable de los files para networkingucir el tráfico de networking para lecturas. Estos directorys se pueden eliminar en cualquier momento.
Una creación de borrador que elimina ~ / work / … y la vuelve a llenar de los files

Pero con DVCS eso no tiene sentido

Los files están en mi máquina de desarrollo, pero un clon cercano está en una máquina remota por razones de respaldo.
Hacer una compilation cero significaría eliminar y volver a extraer todo el file, lo que parece costoso.
Parece que tengo directorys llamados ~ / git / git.git / git, que son muchos gits.

¿La gente hace todo su desarrollo en ~ / git? Si necesita trabajar con versiones de desarrollo, testing, lanzamiento y uso único para grandes clientes, ¿están bajo ~ / git, o pueden estar en otra parte de sus propios treees? ¿A dónde van los componentes de terceros? ¿Es esto demasiado grande para SO (¿necesito leer un libro), o puede responderse con un diagtwig de tree ASCII?

Debido a la forma en que funciona Git, realmente no desea colocar directorys de trabajo para repositorys (o sucursales) en un directory bajo el directory de trabajo para otro repository. Seguiría queriendo poner el contenido de su directory hijo en el repository de los padres.

Si vas con todas las sucursales siendo directorys hermanos, eso funcionaría bien.

Lo que tiendo a hacer (independientemente de usar Git, cvs o (ick) SourceSafe) es tener un directory de Desarrollo, y cada proyecto, twig, etc. debe ser un subdirectory allí.

Estoy de acuerdo con la respuesta de TED ya que prefiero mantener cada proyecto en un directory de desarrollo. Sin embargo, cuando estoy en la terminal mirando una list de bash, me gusta ver fácilmente tres cosas:

¿Qué tipo de repo es este? Git, Mercurial o Subversion
Dónde está almacenado el repository pseudocentral — Github.com, Bitbucket.org, Google Code, etc.
A quién pertenece el repository pseudo-central

Descubrí que puedo hacer esto fácilmente mediante el uso de la siguiente convención de nomenclatura para mis proyectos:

~/development/project.whatwhere.who

Como es común usar Mercurial para clonar un proyecto local, agrego una capa a la estructura del directory como:

 ~/development/project.whatwhere.who/project/ # Initial clone from remote repo ~/development/project.whatwhere.who/project.local.blah_descriptor/ # Local hg clone

La convención whatwhere que uso es la siguiente:

github — Git repo almacenado en github.com
Gitorious — Git repo almacenado en gitorious.org
git — Git repo almacenado en otro lado
gitsvn — Repo de Subversion clonado usando git-svn almacenado en otro lado
hgbit — Repo mercurial almacenado en bitbucket.org
hg.gcode — Repo mercurial almacenado en el código de Google
hg — Repo mercurial almacenado en otra parte
svn.gcode — Repo de Subversion almacenado en el código de Google
svn.sforge — Repo de Subversion almacenado en Sourceforge.net
svn.work —- Repo de Subversion almacenado en el server svn de nuestra compañía
svn — Repo de Subversion almacenado en alguna parte

La convención de who es simplemente el nombre de usuario de la persona deseada.

A continuación hay algunos ejemplos de proyectos, todos residen en mi directory ~/development/ :

 fabric.github.bitprophet # Bitprophet's fabric project cloned from Github fabric.github.myusername # My fork of the fabric project from Github virtualenv.hgbit.ianb # Ianb's virtualenv project cloned from Bitbucket growl.hg.gcode # Growl project cloned from Google code ledgersmb.svn.sforge # LedgerSMB project checked out from Sourceforge coldfire.gitsvn # Coldfire Subversion project at work cloned using git-svn coldfire.svn # Coldfire Subversion project at work checked out with svn

Para ayudar a organizar sus proyectos si obtiene demasiados, es posible que desee agregar una capa inmediatamente debajo del directory ~/development para la organización. Por ejemplo, podría tener los siguientes directorys:

 ~/development/workprojects/ ~/development/opensrcprojects/ ~/development/personalprojects/

Nota : Normalmente uso Git para DVCS, por lo que esta respuesta probablemente esté inclinada en esa dirección.

Intereting Posts

¿Cuál es la diferencia entre Mercurial y Git?¿Qué facilita la fusión en DVCS?¿Por qué mi origen git desea eliminar todos mis cambios push?git vs. subversion Rutinas alternativas cuando se usa Mercurial Hg ¿Puedo hacer una revisión anterior con la propina y el empuje (usando Mercurial)?¿Cómo especifico una combinación de bases para usar en una fusión 'hg'?Almacenamiento seguro de secretos en el control de origen alojado