什么目录结构对于像git这样的DVCS有意义？

What I am used to:

Archives on the servers (NY, IN, NC)

服务器上的档案(NY,IN,NC)

On my development machine:
- A directory named ~/work
- Subdirectories named ~/work/NY/devproject, ~/work/NC/project etc
- Not infrequently, subdirectories named ~/work/NY/release/1.3/project, ~/work/NY/test/1.3b/project etc
- Sometimes directories named ~/proxy/NY, ~/proxy/NC etc which contain a disposable local cache of the archives in order to reduce network traffic for reads. These directories can be deleted at any time.

在我的开发机器上:一个名为〜/ work子目录的目录名为〜/ work / NY / devproject,〜/ work / NC / project等不经常,名为〜/ work / NY / release / 1.3 / project,〜/ work /的子目录NY / test / 1.3b / project等有时名为〜/ proxy / NY,〜/ proxy / NC等的目录,其中包含档案的一次性本地缓存,以减少读取的网络流量。可以随时删除这些目录。

A scratch build that deletes ~/work/... and repopulates it from the archives

一个临时构建,删除〜/ work / ...并从归档中重新填充它

But with DVCS that doesn't make sense

The archives are on my development machine, but a near-clone is on a remote machine for backup reasons.

存档位于我的开发计算机上,但由于备份原因,近端克隆位于远程计算机上。

Doing a scratch build would mean deleting and re-pulling the whole archive, which seems costly.

进行临时构建意味着删除并重新拉动整个存档,这看起来很昂贵。

It looks like I have directories named ~/git/git.git/git which is a lot of gits.

看起来我的目录名为〜/ git / git.git / git,这是很多gits。

Do people do all their development in ~/git? If you need to work with dev, test, release, and one-off-for-big-client versions, are these under ~/git, or can they be elsewhere in their own trees? Where do third-party components go? Is this too big for SO (do I need to read a book), or can it be answered with an ASCII tree diagram?

人们用〜/ git做他们所有的开发吗?如果你需要使用dev,test,release和one-off-for-big-client版本,这些是〜/ git,还是可以在他们自己的树中的其他地方?第三方组件在哪里?这对于SO来说太大了(我是否需要阅读一本书),还是可以用ASCII树图来回答?

2 个解决方案

#1

Because of the way Git works, you really don't want to place working directories for repositories (or branches) in a directory under the working directory for another repository. It would keep wanting to put the contents of your child directory into the parent's repository.

由于Git的工作方式,您实际上不希望将存储库(或分支)的工作目录放在另一个存储库的工作目录下的目录中。它会继续想要将子目录的内容放入父级的存储库中。

If you go with all branches being sibling directories, that would work just fine.

如果你把所有分支都作为兄弟目录,那就可以了。

What I tend to do (regardless of using Git, cvs, or (ick) SourceSafe) is have a Development directory, and each project, branch, etc be a subdirectory in there.

我倾向于做(无论使用Git,cvs还是(ick)SourceSafe)都有一个Development目录,每个项目,分支等都是一个子目录。

#2

I agree with T.E.D.'s answer in that I prefer to keep each project in a development directory. However, when I'm in the terminal looking at a bash listing I like to easily see three things:

我同意T.E.D.的回答,因为我更喜欢将每个项目保留在开发目录中。但是,当我在终端查看bash列表时,我喜欢轻松看到三件事:

What type of repo is this --- Git, Mercurial, or Subversion

这是什么类型的回购--Git,Mercurial或Subversion

Where is the pseudo-central repo stored --- Github.com, Bitbucket.org, Google Code, etc.

存储的伪*仓库在哪里--- Github.com,Bitbucket.org,Google Code等。

Who owns the pseudo-central repo

谁拥有伪*回购

I've found that I can easily do this by using the following naming convention for my projects:

我发现我可以通过对我的项目使用以下命名约定来轻松完成此操作:

~/development/project.whatwhere.who

Since it is common when using Mercurial to clone a local project, I add one layer to the directory structure as:

由于在使用Mercurial克隆本地项目时很常见,因此我在目录结构中添加了一个图层:

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

The whatwhere convention that I use is as follows:

我使用的地方约定如下:

github --- Git repo stored on github.com

github --- git repo存储在github.com上

gitorious --- Git repo stored on gitorious.org

gitorious --- git repo存储在gitorious.org上

git --- Git repo stored somewhere elsewhere

git --- Git repo存储在别处的某个地方

gitsvn --- Subversion repo cloned using git-svn stored somewhere else

gitsvn ---使用git-svn克隆的Subversion repo存储在其他地方

hgbit --- Mercurial repo stored on bitbucket.org

hgbit ---存储在bitbucket.org上的Mercurial repo

hg.gcode --- Mercurial repo stored on Google code

hg.gcode ---存储在Google代码上的Mercurial仓库

hg --- Mercurial repo stored elsewhere

hg --- Mercurial repo存储在别处

svn.gcode --- Subversion repo stored on Google code

svn.gcode ---存储在Google代码上的Subversion repo

svn.sforge --- Subversion repo stored on Sourceforge.net

svn.sforge ---存储在Sourceforge.net上的Subversion repo

svn.work ---- Subversion repo stored on our company's svn server

svn.work ----存储在我们公司的svn服务器上的Subversion repo

svn --- Subversion repo stored somewhere

svn --- Subversion repo存储在某个地方

The who convention is simply the username of the desired person.

约定只是所需人员的用户名。

Below are a few project examples, all residing in my ~/development/ 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

To help organize your projects if you get too many, you may want to add a layer immediately beneath the ~/development directory for organization. For example, you could have the following directories:

如果太多,可以帮助组织项目,您可能希望在〜/ development目录下面添加一个用于组织的层。例如,您可以拥有以下目录:

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

Note: I typically use Git for DVCS, so this answer is most likely slanted in that direction.

注意:我通常使用Git进行DVCS,因此这个答案很可能倾向于这个方向。

#1