一个SVN存储库中多个项目的文件夹结构？

我刚刚创建了一个SVN存储库，用于存储我的学校项目和家庭作业，并允许在学校和家庭之间轻松传输

它创建的默认目录是：

我从来没有为一个以上的项目使用过一个存储库，但在阅读之后：我决定为所有随机的学校项目使用一个存储库

我是否应该复制上面的文件夹结构，但要针对每个项目

---

这就是一个回购协议中的多项目人员所做的吗？

这就是我在我的家庭源代码管理中使用的

我只有一个主存储库

存储库/项目1/主干
存储库/项目1/标签
存储库/项目1/分支

存储库/项目2/主干
存储库/项目2/标签
存储库/项目2/分支

---

我喜欢这种结构，它很容易引用项目并保持完整性。

这个问题没有明确的答案，因为它取决于什么最适合您的项目

我会使用/projectA/trunk布局，如果每个项目都在进行大量的开发，并且所有东西都需要分离，因为它们之间没有太多的连接（独立的组件/项目）。但是，您也可以为每个项目使用一个SVN存储库。请记住，您将无法使用svn co签出所有项目http://..../svn/ 因为这还将从所有项目中获取所有标记和分支，而不仅仅是主干。

/trunk/projectA如果您的项目/组件紧密地属于一起，并且您需要从同一版本中对它们进行标记和分支，那么肯定会更好（就像一个与主项目关系密切的库）您也可以使用svn cohttp://.../svn/trunk/ 获取所有项目的最新主干版本（如果您愿意）

从可维护性的角度来看，我几乎总是倾向于第二种方法；但是如果您的项目变得更大，并且可能会延长，那么最好对每个项目使用单独的存储库

---

除此之外：请检查你的作业是否真的需要谷歌代码服务，因为它的目的是支持OSS。你可以在本地甚至通过SSH使用SVN，因此你也可以将你的存储库放在U盘或可以远程访问的计算机上；你不需要托管。也可以有privacy关注点。

您有两个选择。您已经提到的一个，即每个项目都有一个中继（选项1）：

选项2将有一个主干，每个项目都是主干下的子文件夹：

https://simucal-projects.googlecode.com/svn/trunk/projectA/
https://simucal-projects.googlecode.com/svn/tags/projectA/
https://simucal-projects.googlecode.com/svn/branches/projectA/

https://simucal-projects.googlecode.com/svn/trunk/projectB/
https://simucal-projects.googlecode.com/svn/tags/projectB/
https://simucal-projects.googlecode.com/svn/branches/projectB/

选项1的优点是您可以独立地对每个项目进行分支和标记。如果您需要单独部署每个项目，这是可取的

如果所有项目都部署在一起，那么选项2是可取的。这是因为在部署时只需标记一次存储库

由于您在学校项目中使用Subversion，您需要问问自己是否需要标记您的工作。您还可以问问自己是否需要创建分支（如果您想尝试一下，您可能会想创建分支）。您还需要问自己是否愿意将所有工作作为一个整体进行分支，您是否更喜欢独立分支每个项目的灵活性

我一直遵循的经验法则是：将我们一起部署的任何东西都集中在一起

---

（顺便说一句，在同一个存储库中可以有多个中继，这几乎相当于在多个存储库中有一个中继，只是每个存储库都有自己的修订计数器，并且您不能在存储库之间合并。）

如果您坚持只拥有一个存储库（我自己也在“不要露营”中）然后做分支，然后我认为您的建议是好的。但是，再次，我认为一个VSN存储库等于一个项目。

< P>一个真实的例子：Apache Projcess。

< P>一个主要的目标是跟踪文件夹布局（在版本控制中），是访问控制管理。 如果需要分离开发团队（负责主干）和维护团队（负责分支机构），那么这种结构很好：

/trunk
      /Project1
      /Project2
/branches
         /Project1
         /Project2
/tags
     /Project1
     /Project2

/Project1
         /trunk
         /branches
         /tags
/Project2
         /trunk
         /branches
         /tags

如果我们想允许每个项目访问特定的用户组，这种结构很好：

/trunk
      /Project1
      /Project2
/branches
         /Project1
         /Project2
/tags
     /Project1
     /Project2

/Project1
         /trunk
         /branches
         /tags
/Project2
         /trunk
         /branches
         /tags

---

我的项目重量很轻。存储库的全部意义在于，我能够为学校完成所有的小项目，而不必随身携带代码。为每个小项目建立一个存储库会很麻烦。好吧，我的代码~将~开源，仅仅因为它是为学校编写的并不意味着n它没有任何潜在价值。尤其是我在遗传算法方面的工作，人们可能会觉得它很有价值。谷歌代码正是为此而设计的。我不是一个拇指驱动型的人，SVN本地版有点挫败了我最初尝试设置它的目的。可移植性。也许你愿意尝试一下解惑（）。他们将为您提供一个免费的svn存储库，您的代码可以是私有的。我强烈支持这种布局。我听Pawel说，如果存储库在svn中像在git中一样易于创建和管理，我会同意。但是如果您可以将每个项目视为自己的存储库，那么一切都会很好地工作。没错，在sce中nario也描述了使用多存储库布局似乎不切实际。您可以对主存储库进行简单的获取，以选择所有代码或单独获取每个项目。此外，VS2008和AnkhSVN 2.0非常易于管理，易于使用多项目解决方案等@Simucal我认为这应该是公认的答案-thanks特朗普！