我为一家主要业务与软件无关的公司工作。大多数使用源代码控制的文档都是在开发团队为商业或者开源项目编写的时候编写的。作为编写内部软件的人，我可以说工作是不同于在商业或者开源环境中进行的。此外，还有一些存储过程和数据库脚本需要与代码保持同步。

特别是，我正在寻求有关如何最好地使用内部软件来构造存储库的建议。大多数文档都建议使用主干，分支，标签等。以及使生产，测试和开发环境与其存储库中的各个部分保持同步的过程等。

解决方案

回答

我们可以使用www.unfuddle.com之类的服务来建立免费的SVN或者GIT存储库。

我们使用Unfuddle，它的确很棒。有免费和付费版本(取决于需求)。

或者，我们当然可以设置本地副本。可以通过Google找到大量的相关教程：http://www.google.com/search?rlz=1C1GGLS_enUS291&aq=f&sourceid=chrome&ie=UTF-8&q=set+up+svn

回答

如该线程中所指定，由于易于创建分支，易于合并分支，无需设置特殊服务器，无需网络访问工作以及其他一些功能，因此分布式VCS(git，Mercurial)比集中式VCS是更好的模型。好处。如果我们一个人工作，DVCS允许我们在需要时很容易地将人员纳入项目。

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

回答

对于Subversion，也有Trac和其他有用工具随附的Assembla。它是免费的，或者如果每个项目需要更多空间或者用户，则可以为一个帐户付费。

回答

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

这是一篇有关设置svn + ssh的文章，其中包含安全注意事项。如果我们了解所有这些内容并按照以下步骤进行操作，那么我们将有一个良好的开端。

本文介绍了多种方法来进一步保护svn帐户的ssh登录。

我建议创建专门用于svn访问的帐户，而没有对该服务器的其他访问权限。我的猜测是，我们将使用每日构建或者自动脚本来更新数据库中存储的proc。每日构建可以具有自己的特殊帐户和自己的ssh密钥。我不希望我的自动化工具与人类用户使用相同的登录名运行(因此我知道哪个工具已损坏)。

如果我们不了解所有安全技巧，则搜索google可以为我们提供一些帮助。如果遇到问题，请先设置一个没有安全性的技巧。这样一来，故障排除就变得更加简单。

祝我们好运，并享受源代码管理的好处！

回答

一个项目的存储库可能就足够了。我喜欢按项目对布局进行索引的典型方法(请参阅O'Reilly Subversion书中的本节)：

/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更具弹性，对于小型团队/项目而言，结帐的速度并不是很多问题。我们可以自己比较和决定。

食谱的其他标准部分包括Trac和最小的Linux服务器，用于在LAN上托管资源库。

回答

仅在组织方式方面，设置SVN储存库可能很棘手。在设置SVN之前，我实际上是RTFM编写了在线Subversion手册，该手册讨论了存储库的组织技术以及我们应事先考虑的一些陷阱，即如果我们决定改变主意，则在创建存储库后将无法执行的操作。我建议在安装之前先通读本手册。

对于我们来说，作为顾问，我们通过SVN进行自定义和内部软件开发以及一些文档管理。为每个客户创建一个存储库，为我们自己创建一个存储库符合我们的利益。在每个存储库中，我们为每个项目(软件或者其他)创建了文件夹。这使我们能够按存储库，按客户端甚至按存储库内的项目对安全访问进行细分。更深入地讲，对于每个软件项目，我们都创建了"工作"，"标签"和"分支"文件夹。我们通常使用" release_w.x.y.z"作为标准标签，将发布放在"标签"中。

对于情况，要使存储库，脚本和其他相关文档保持同步，可以创建一个项目文件夹，然后在"工作"文件夹下，然后在"代码"下，在"脚本"旁边，等等。当我们标记要发布的工作版本时，最终将它们全部标记在一起。

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

至于非代码，我建议按项目或者文档类型(手册，策略等)使用直接的文件夹布局。通常，使用文档并根据我们公司的运作方式，只需拥有版本历史记录/日志即可。

我们在Windows上与WebSVN一起在SVN上运行，WebSVN是一个很棒的开源资源库查看器。我们使用它为客户提供对其代码的Web访问，而这一切都由底层Subversion安全性驱动。在内部，我们使用TortoiseSVN来管理存储库，提交，更新，导入等。

另一件事是，培训应被视为部署的组成部分。刚接触版本控制的用户可能很难理解发生了什么。我们发现，在他们学习概念时，给他们提供功能说明(在创建项目时执行此操作，在更新时执行此操作等)非常有用。我们创建了一个"沙盒"存储库，用户可以在其中使用文档和文件夹来播放所需的所有内容以进行练习，我们可能会发现这对尝试建立哪些策略也很有用。

祝你好运！

回答

发布此问题后，我与一位同事交谈，他建议我阅读这篇文章：

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

简而言之，它提倡程序员更加注意分支。它帮助我看到没有正确的方法来组织我们的存储库。对于我们的团队，我们将有一个主干和两个长期分支进行测试和开发。此外，在将任务升级到测试和生产时，我们将为每个任务创建单独的分支，并合并任务分支中的更改。

回答

我相信遵循基本模式，并在其下具有树干，标签，分支的项目目录。我通常喜欢这样设置顶层

项目包含所有单个项目或者模块
发布包含涉及多个模块的发布标签
用户拥有私人用户分支
管理员保存我的挂钩脚本，备份脚本等。

如果产品由多个模块组成，而这些模块对于特定的发行版可能都是不同的标签(一个环将它们绑定在一起)，则发行版标签很有用。它使源代码托管和开发人员更容易引用组成发行版1或者2的内容。

回答

我同意使用躯干/分支/标签的通用约定。除此之外，我认为我们可能正在寻找类似"如何组织版本控制存储库？"中的答案的内容。