你将如何为内部软件项目组织一个Subversion版本库？

我为一家主要业务与软件无关的公司工作。大多数使用源代码管理的文档都是由开发团队编写的，这些团队都是为商业或开源项目编写的。作为编写内部软件的人，我可以说工作的完成方式不同，那么它将处于商业或开源的环境。另外还有需要保持与代码同步的存储过程和数据库脚本。你将如何为内部软件项目组织一个Subversion版本库？

特别，我希望得到有关如何最好地在内部软件记住结构库的建议。大多数文档建议树干，树枝，用各自的部分保持生产，测试和开发环境中同步存储库中的标签等和程序等

来源

2008-09-09 minty

你可以使用一个类似的服务来www.unfuddle.com成立了免费的SVN或GIT存储库。

我们使用Unfuddle，它真的很棒。有免费和付费版本（取决于您的需求）。

或者，你当然可以设置一个本地副本。有很多教程通过谷歌被发现为：http://www.google.com/search?rlz=1C1GGLS_enUS291&aq=f&sourceid=chrome&ie=UTF-8&q=set+up+svn

来源

2008-09-09 04:24:03 Eric

如this thread规定，分布式VCSS（GIT，水银），比集中的人一个更好的模型，由于分公司创建放心，分支合并放心，没有必要设置一个特殊的服务器，无需网络访问工作和其他一些优势。如果你一个人工作，DVCS可以让你将人员纳入你的项目，如果需要很容易出现的话。

无论如何，直接回答您的问题，设置SVN的一种方法是为每个项目设置一个存储库，并根据存储过程，脚本和库是否共享，在脚本的每个项目树上创建一个目录和存储过程，或共享代码的完整存储库。

来源

2008-09-09 04:30:18

颠覆，有Assembla也附带Trac和其他有用的工具。它是免费的，或者如果您需要更多空间或每个项目的用户，您可以支付一个帐户。

来源

2008-09-09 04:41:20 marcospereira

对于我的公司，我使用svn + ssh和基于密钥的身份验证。您可以使用Windows客户端和Linux客户端来执行此操作。当您使用ssh密钥登录而不是输入密码时，直接获得密钥，这真的很容易使用。

Here's an article on setting up svn+ssh与安全注意事项。如果你理解了所有这些东西并按照这些步骤操作，那么你将会有一个良好的开端。

This article描述了多种方式来进一步保护您的ssh登录为SVN账户。

我建议专门为svn访问创建帐户，而不能访问该服务器。我的猜测是，你会使用每日构建或自动脚本来更新你存储在数据库中的特效。每日构建可以有自己的特殊帐户和他们自己的ssh密钥。我不喜欢我的自动工具使用与人类用户相同的登录名运行（所以我知道哪个工具已损坏）。

如果你不明白所有的安全技巧的，谷歌搜索可以让你一些帮助。如果遇到问题，请先安装一个，不要使用安全技巧。这使得故障排除变得更简单。

祝你好运，享受源代码管理的好处！

来源

2008-09-09 05:02:12 Mnebuerquo

您的项目的一个存储库可能就足够了。我喜欢典型的做法是通过指标项目布局（见从O'Reilly Subversion book this section）：

/first-project/trunk 
/first-project/branches 
/first-project/tags 
/another-project/trunk 
/another-project/branches 
/another-project/tags 
/common-stuff/trunk 
/common-stuff/branches 
/common-stuff/tags

请记住，你总是可以在以后重新组织库。另外，对于内部的东西，我更喜欢FSFS的数据存储，而不是Berkeley DB。 FSFS更具弹性，对于小团队/项目而言，结账速度并不太受关注。你可以compare并自己决定。

配方的其他标准部分包括Trac和一个最小的Linux服务器来托管局域网上的存储库。

来源

2008-09-09 05:07:38

只有从组织方式的角度来看，设置SVN存储库可能会很棘手。在我们设置SVN之前，我实际上是RTFM的在线Subversion manual，它讨论了存储库的组织技巧以及您应该事先考虑的一些问题，即在您创建存储库后如果您决定改变主意，您无法做的事情。我建议在安装之前先通读本手册。

对于我们来说，作为顾问，我们通过SVN进行定制和内部软件开发以及一些文档管理。我们有兴趣为每个客户创建一个存储库，并为我们自己创建一个存储库。在每个存储库中，我们为每个项目（软件或其他）创建了文件夹。这使我们能够根据存储库和客户端甚至是存储库中的项目来分割安全访问。进一步来说，我们为每个软件项目创建了“工作”，“标签”和“分支”文件夹。我们通常使用'release_w.x.y.z'作为标准的标签，将版本放在'标签'中。

在你的情况下，为了保持sprocs，脚本和其他相关文档的同步，你可以创建一个项目文件夹，然后在'working'文件夹下，然后在'code'下并且在'scripts'等等。然后，当您为发布版本标记工作版本时，您最终将它们标记在一起。

\Repository 
    \ProjectX 
     \Working 
     \Code  
     \Scripts 
     \Notes  
     \Tags 
     \Branches

至于非代码，我建议按项目或文档类型（手册，政策等）直板夹布局。一般情况下，根据公司的运作情况，只有版本历史记录就足够了。

我们在Windows上运行SVN以及WebSVN这是一个很好的开源存储库查看器。我们使用它来让客户可以访问他们的代码，并且这些都由Subversion的Subversion安全性驱动。在内部，我们使用TortoiseSVN来管理存储库，提交，更新，导入等。

另一件事是培训应该被视为部署的一个组成部分。版本控制的新用户可能很难理解正在发生的事情。我们发现给他们提供功能指令（在创建项目时这样做，在更新时执行此操作等）在学习概念时非常有用。我们创建了一个“沙盒”存储库，用户可以在其中随时随地用文档和文件夹进行练习，您可能会发现这也很有用，可以尝试制定哪些策略。

祝你好运！

来源

2008-09-09 05:35:14

请注意，建立的顶层文件夹标准是`trunk，branches，tags`。如果您使用`working`而不是`trunk`，则会混淆许多与SVN回购协同工作的工具。我强烈劝阻这样做。 – sleske 2012-06-18 14:38:42

张贴这个问题，我与谁建议同事发言后，我读了文章：

http://www.codinghorror.com/blog/archives/000968.html

总之，它主张的程序员更加了解分支。它帮助我看到组织我们的存储库没有正确的方法。对于我们的团队，我们将有一个主干和两个长期分支机构进行测试和开发。此外，我们将为每项任务分别制作分支，并合并来自任务分支的更改，以便将任务推广到测试和生产。

来源

2008-09-10 19:39:40 minty