我在一家主要业务与软件无关的公司工作。大多数使用源代码控制的文档都是由开发团队为商业或开源项目编写的。作为编写内部软件的人,我可以说工作的完成方式与商业或开源环境不同。此外,还有需要与代码保持同步的存储过程和数据库脚本。
特别是,我希望获得有关如何最好地考虑内部软件来构建存储库的建议。大多数文档都建议使用主干、分支、标签等。以及使生产、测试和开发环境与存储库中的相应部分保持同步的程序等。
我在一家主要业务与软件无关的公司工作。大多数使用源代码控制的文档都是由开发团队为商业或开源项目编写的。作为编写内部软件的人,我可以说工作的完成方式与商业或开源环境不同。此外,还有需要与代码保持同步的存储过程和数据库脚本。
特别是,我希望获得有关如何最好地考虑内部软件来构建存储库的建议。大多数文档都建议使用主干、分支、标签等。以及使生产、测试和开发环境与存储库中的相应部分保持同步的程序等。
仅在您如何组织它们的意义上,设置 SVN 存储库可能会很棘手。在我们设置 SVN 之前,我实际上是 RTFM 的在线Subversion 手册,其中讨论了存储库的组织技术以及您应该提前考虑的一些问题,即如果您决定改变主意,在创建存储库后不能做什么. 我建议在设置之前通过本手册。
对于我们来说,作为顾问,我们通过 SVN 进行定制和内部软件开发以及一些文档管理。为每个客户创建一个存储库并为我们自己创建一个存储库符合我们的利益。在每个存储库中,我们为每个项目(软件或其他)创建了文件夹。这使我们能够按存储库和客户端甚至存储库中的项目来划分安全访问。更深入地讲,我们为每个软件项目创建了“工作”、“标签”和“分支”文件夹。我们通常使用“release_w.xyz”作为标准的标签将发布放在“标签”中。
在您的情况下,为了使存储过程、脚本和其他相关文档保持同步,您可以创建一个项目文件夹,然后在该“工作”文件夹下,然后在该“代码”下,在它旁边的“脚本”等。然后当您将工作版本标记为发布时,您最终会将它们全部标记在一起。
\Repository
\ProjectX
\Working
\Code
\Scripts
\Notes
\Tags
\Branches
至于非代码,我建议按项目或文档类型(手册、政策等)直接文件夹布局。通常带有文档并取决于您公司的运营方式,仅具有版本历史记录/日志就足够了。
我们在 Windows 上运行 SVN 以及WebSVN,它是一个很棒的开源存储库查看器。我们使用它让客户可以通过网络访问他们的代码,这一切都由底层的 Subversion 安全性驱动。在内部,我们使用TortoiseSVN来管理存储库、提交、更新、导入等。
另一件事是培训应被视为部署的一个组成部分。刚接触版本控制的用户可能很难理解发生了什么。我们发现向他们提供功能说明(在创建项目时执行此操作,在更新时执行此操作等)在他们学习概念时非常有帮助。我们创建了一个“沙盒”存储库,用户可以在其中使用文档和文件夹来练习他们想要的所有内容,您可能会发现这对于尝试建立哪些策略也很有用。
祝你好运!
发布此问题后,我与一位建议我阅读这篇文章的同事交谈:
http://www.codinghorror.com/blog/archives/000968.html
简而言之,它提倡程序员更加注意分支。它帮助我看到没有正确的方法来组织我们的存储库。对于我们的团队,我们将有一个主干和两个用于测试和开发的长期分支。此外,我们将为每个任务创建单独的分支,并在我们将任务升级到测试和生产时合并来自任务分支的更改。
您可以使用 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
您的项目的一个存储库可能就足够了。我喜欢按项目索引布局的典型方法(请参阅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和一个用于在 LAN 上托管存储库的最小 Linux 服务器。
我同意使用主干/分支/标签的通用约定。除此之外,我认为您可能正在寻找类似我在如何组织版本控制存储库中的答案?.
对于我的公司,我使用 svn+ssh 和基于密钥的身份验证。您可以使用 Windows 客户端和 linux 客户端执行此操作。一旦您直接使用 ssh 密钥登录而不是输入密码,这将非常容易使用。
这是一篇关于设置 svn+ssh并附有安全说明的文章。如果您了解所有这些内容并遵循这些步骤,那么您将有一个良好的开端。
本文介绍了多种方法来进一步保护 svn 帐户的 ssh 登录。
我建议专门为 svn 访问创建帐户,而不能访问该服务器。我的猜测是您将使用每日构建或自动化脚本来更新您存储在数据库中的过程。每日构建可以有自己的特殊帐户和自己的 ssh 密钥。我不喜欢我的自动化工具以与人类用户相同的登录名运行(所以我知道哪个工具坏了)。
如果您不了解所有的安全技巧,搜索 google 可以获得一些帮助。如果您遇到问题,请先设置一个没有安全技巧的设备。这使得故障排除更简单一些。
祝你好运,享受源代码控制带来的好处!
我相信遵循基本模式,项目目录下有主干、标签、分支。我通常喜欢像这样设置顶层
Projects 保存所有单个项目或模块 Releases 保存涉及多个模块的发布标签用户保存私有用户分支 Admin 保存我的钩子脚本、备份脚本等。
如果您的产品由多个模块组成,这些模块都可能是特定版本的不同标签(一个环来绑定它们等等),则发布标签很有用。它使源代码托管和开发人员可以轻松参考构成第 1 版或第 2 版的内容。
如本线程所述,分布式 VCS(git、Mercurial)是比集中式 VCS 更好的模型,因为分支创建容易、分支合并容易、无需设置特殊服务器、无需网络访问工作等优点。如果您将独自工作,DVCS 允许您在需要时将人员整合到您的项目中。
无论如何,直接回答您的问题,设置 SVN 的一种方法是为每个项目创建一个存储库,并根据是否共享存储过程、脚本和库,在每个项目树上为脚本和存储过程创建一个目录,或共享代码的完整存储库。