颠覆结构问题

刚从视觉工作室转向颠覆...... 我已经爱上了!有人可以简单解释一下

知识库

分行

标签

树干

我是否需要为每个项目创建一个新的存储库？还是新的行李箱？

谢谢

您不需要单独的存储库,但如果需要,也可以.我建议您阅读http://svnbook.red-bean.com/上的这本书.抓住pdf版本或其他任何东西.它不需要太长时间,它可以很好地解释一些事情.我读了它,发现我很高兴我做到了.

请记住,subversion只是一个支持版本控制的奇特文件系统.将存储库视为"驱动器根",如"C:/".

每个项目都有一个trunk,tags和branches目录.你的所有日常工作都发生在后备箱里.实验代码在分支中完成,然后在以后合并回主干.标签适用于您发布软件时.这些不会被编辑.当您发布该软件时,您将根据当前在主干中的内容创建一个具有唯一名称的标记.

我不能说你是否需要为每个项目单独的存储库,有利有弊.这篇博文详细介绍了它们:

简化管理.部署一组钩子.一个备份存储库.等等

分支/标签灵活性.将代码全部放在一个存储库中,可以更轻松地创建涉及多个项目的分支或标记.

轻松移动代码.也许您想从一个项目中获取一部分代码并在另一个项目中使用它,或者将其转换为多个项目的库.在同一个存储库中移动代码很容易,并保留代码的历史记录.

以下是单一存储库方法的一些缺点,即多存储库方法的优点.

尺寸.处理许多较小的存储库可能比一个较大的存储库更容易.例如,如果您退出项目,则只需将存储库存档到介质并将其从磁盘中删除并释放存储空间.也许您需要出于某种原因转储/加载存储库,例如利用新的Subversion功能.如果它是一个较小的存储库,这样做更容易,影响更小.即使您最终想要对所有存储库执行此操作,一次执行一个存储库的影响也会较小,假设没有迫切需要一次完成所有存储库.

全球修订号.即使这不应成为一个问题,但有些人认为它是一个问题,并且不希望看到修订版号在存储库中前进,而且不活动的项目在修订历史中有很大的差距.

访问控制.虽然Subversion的authz机制允许您根据需要限制对存储库的某些部分的访问,但在存储库级别执行此操作仍然更容易.如果您的项目只有少数几个人可以访问,那么使用该项目的单个存储库更容易.

行政灵活性.如果您有多个存储库,则根据存储库/项目的需要更容易实现不同的钩子脚本.如果您需要统一的钩子脚本,那么单个存储库可能会更好,但如果每个项目都需要自己的提交电子邮件样式,那么将这些项目放在单独的存储库中会更容易

我同意,阅读svnbook.这是一个很好的资源.

我是否需要为每个项目创建一个新的存储库？还是新的行李箱？

Kevin非常清楚地涵盖了单/多存储库的权衡.当我们开始使用svn时,我们为所有开发项目使用了一个存储库.它运作良好,具有所提到的所有优点.但是,随着存储库变得越来越大,由于转储文件的大小以及备份期间产生的问题,管理起来变得更加困难.它也成为一个问题,项目无法轻易地从存储库中存档 - 这当然是可能的,但它需要从存储库中转储和提取项目.它们不是你无法解决的问题,但要注意这一点.

知识库

分行

标签

树干

分支,标签和主干只是存储库中包含的文件的副本.它允许您在适当的任何时间(通常在发布或功能分支)分隔和检查文件.

关于分支,标签和主干的一个重要事项是它们只是svn中的约定.这三个位置之间没有功能差异,它们只是一种可接受的使用模式,如果您有充分的理由,它们可以进行不同的更改或组织.我不建议你组织不同,但你会发现svn非常灵活,因为除了惯例之外,没有真正的强制组织结构.

根据您决定在存储库中拥有的项目数量,您可以采用不同的方式进行组织.

您可以在其下包含项目的子目录:

\repo
  \branches
    \...
  \tags
    \...
  \trunk
    \..

或者您可以让项目包含子目录:

\repo
  \Project1
    \branches
    \tags
    \trunk
  \Project2
    \branches
    \tags
    \trunk

svnbook中有一些权衡取舍.如果每个存储库只有一个项目,则通常使用第一种方法;如果存储库中有多个项目,则通常使用第二种方法.

好消息是你可以开始使用svn然后找出你喜欢的东西.您应该有某种组织,但是,通过廉价的副本,您可以随着情况或工作流程的变化重新安排文件夹.