DVCS(Mercurial)不适合我吗?

DVCS(Mercurial)不适合我吗?,mercurial,dvcs,subrepos,Mercurial,Dvcs,Subrepos,我在一家公司工作,在那里我们创建了许多针对特定客户的小型应用程序。 我们是少数几个开发者,但大多数时候每个项目只有一个开发者 Customer1 ProjectX App Tests ProjectY App Tests Customer2 Project2 Products Product1 Common 如今,所有内容都存储在一个存储库中 这个过程很简单 开发人员为客户承担新项目 为项目创建新文

我在一家公司工作,在那里我们创建了许多针对特定客户的小型应用程序。 我们是少数几个开发者,但大多数时候每个项目只有一个开发者

Customer1
    ProjectX
        App
        Tests
    ProjectY
        App
        Tests
Customer2
    Project2
Products
    Product1
Common
如今,所有内容都存储在一个存储库中

这个过程很简单

  • 开发人员为客户承担新项目
  • 为项目创建新文件夹
  • 新项目中的代码
  • 在另一个项目中进行一些维护
  • 签入维护项目的更新
  • 新项目中的更多工作
  • 签入新项目
  • 交付给客户
  • 没有标记也没有分支。早期版本是基于日期签出的

    这一过程多年来一直运行良好,但当前工具(CVS)存在一些难点

    • 慢点。即使没有任何变化,结账也需要几分钟。历史记录存储在服务器上,因此差异花费的时间太长
    • 添加新项目。若你们使用CVS,你们知道它是这样的:添加文件夹,在文件夹中添加文件,添加下一个文件夹
    • 无法回退明显错误(签入二进制文件等)
    • 不支持重命名,这使得必要的重构更加痛苦
    我私下使用Mercurial已经有一段时间了,我想将它扩展到所有开发人员

    我可能完全弄错了,但有一些事情我不知道如何在我们的组织中实施

    CVS提交仅为当前文件夹,但在mercurial中,它们是存储库范围的。 在我们的例子中,这意味着在一个文件夹中提交维护工作也将在另一个文件夹中提交尚未完成的内容。 (我假设我们可以在已更改的文件夹中执行
    hg ci./**
    ,但合并时不允许这样做,至少文档中是这么说的
    如果您提交合并结果,请不要提供任何文件名或-I/-X筛选器。

    Mercurial的常见做法是每个项目有一个存储库

    Customer1
        ProjectX
            App
            Tests
        ProjectY
            App
            Tests
    Customer2
        Project2
    Products
        Product1
    Common
    
    每个项目一个存储库对我们来说是可以的,但它会产生一些其他问题,如:

    如何管理中央服务器上的多个存储库?
    如果开发人员创建了一个新项目,他最终需要推动他的更改。 正在做

    hg推送

    使用难看的堆栈转储使hg Web服务器崩溃,并挂起客户端

    我的理解是,开发人员需要访问服务器外壳以将新存储库添加到配置文件并重新启动hgweb

    另一种方法是使用SSH或共享 (使用SSH而不是文件共享是否有好处?)

    可以,但对某些开发人员来说有点复杂

    所有开发人员都需要拥有所有项目。
    (并非所有项目都有关联,但许多项目都有关联,因此它们需要存在,而且最容易的方法是全部拥有)

    随着许多现有的项目和新的每周增加,我们需要一种方法,拉在一次过所有的项目,也克隆新的

    我原以为次级回购可以解决“全球”拉力,但以下几点 文档中的行是一个showstopper

    “当我们提交时,Mercurial将尝试创建整个项目及其子项目状态的一致快照。 它通过首先尝试在所有修改的子repo中提交,然后记录所有子repo的状态来完成此操作。”

    回到全局提交的单个存储库问题

    (尝试了一些
    hg ci.hgsub.hgsubstate
    的变体,但是.hgsubstate似乎只在完全提交时更新。如果项目文件夹中没有明确的
    hg pull--update
    ,其他用户将看不到项目更改)

    我目前的想法是在根目录中有一个批处理文件,用于提取所有项目

    关于如何在我们的组织中使用mercurial还有其他想法吗

    编辑

    谢谢你的回复。我目前正在评估每个项目一个存储库将如何为我们工作。我在顶层放置了一个批处理文件

    FOR /F %%x IN (repolist.txt) DO (
        If EXIST .\%%x\.hg (
            ECHO Pull %%x
            hg pull --update --repository .\%%x
        ) ELSE (
            ECHO Clone %%x
            mkdir .\%%x
            hg clone --pull %1\%%x .\%%x
        )
    )
    

    你说Mercurial是为每个回购协议设计的一个项目,这是正确的。这样做也会更好,因为不同项目的历史记录是分开的

    尝试在DVCS回购中拥有多个项目只会带来痛苦

    就个人而言,我更喜欢通过SSH而不是HTTP为项目提供服务。一个原因是有能力

    # hg init blah
    # hg clone blah ssh://server/blah
    
    如果您是通过HTTP提供服务,这是行不通的(正如您所发现的)。我很惊讶它会导致严重的碰撞:-/

    获取所有项目的子回购方法与您描述的不完全一样。这并不是说您回到了全局提交(项目可以单独开发),而是超级项目存储了它所依赖的子项目的版本。如果您(例如)有一个库作为子项目,那么这正是您想要的,但是版本取决于特定的版本。实际上,子回购链接是指向特定版本的另一回购的书签

    但不是你想要的

    可能,常见的东西应该是需要它的项目的子回购。然后,每个项目可能会冻结在同一代码的不同版本上,而您不会遇到任何问题。这需要考虑一下

    否则,脚本的想法可能是最简单的