2

这是一个过程问题，所以可能有不止一个正确答案。不过，我会接管我现在所拥有的一切。

我的团队最近转而使用 Mercurial（来自 Subversion），并且在大多数情况下，我们喜欢新的功能。但是，有一些事情会降低生产力。其中一件事是管理.hgignore文件。

根据既定文献和“互联网上的一些人”的建议:)，我们的团队正在使.hgignore文件保持最新状态，以便hg addremove始终做正确的事情。此外，缺少需要添加的文件是构建失败的第一大原因，因此hg st只返回真正需要操作的文件很重要。

问题是，由于我们总是在文件底部添加新的忽略，如果两个人进行.hgignore更改，总是会导致合并冲突。（大多数人使用 TortoiseHg 客户端，它添加到文件的末尾。）这样做的结果是大约一半的文件被更改，更改它的人必须处理.hgignore. 这感觉很像不得不对我们的源代码控制的内部进行修改。

这导致开发人员不想将文件添加到.hgignore. 我们有一个相当大的项目，有一个相当大的团队正在不断变化。相当定期地引入新的构建工件，因此问题似乎不会消失。.hgignore由于项目正在发生很大变化，因此并没有真正稳定下来。（当然，这本身就是一个不同的问题。）

做的“正确”事情几乎总是“采取双方”。从技术上讲，两个人可能已经使用文本编辑器修改了完全相同的前一行，但这极不可能。即使“双管齐下”的方法失败了，后果也很可能是微不足道的。

所以，我向社区提出了一个问题：我怎样才能改善这种情况？是否有可以缓解这种情况的流程变更？有没有自动取两边的工具？我可以以某种方式自动化合并吗？是否有一个复选框可以检查以神奇地解决问题:)？

编辑 1：这是我当前的 .hgignore 的（显然已编辑）版本。您可以很容易地观察到使用了几种不同的技术。代码的几个部分正在从一种技术转换到另一种技术（例如 VB 到 C#）。这会导致构建工件集发生更改，并且需要更新文件。

syntax: glob
*.obj
*.tds
*.map
*.il?
*/obj/*
*/lib/*
*/pch/*
Foo/Engine/frezbat/DocFiles.hpp
Foo/Engine/personal_defines.h
Foo/Engine/revision.cpp
Foo/Engine/frobbish/uLinkHlp.hpp
Foo/Engine/dll/XMLData/**.xml
Foo/Engine/dll/*.syslog
Foo/Engine/dll/*.log
Foo/Engine/dll/Scripts
Foo/Engine/dll/Linked Models
Foo/Engine/dll/prv
Foo/Engine/dll/pub
Foo/Engine/dll/failures.txt
Foo/Engine/dll/users.prm
Foo/Engine/tools/SrvIface/**.dll
Foo/Engine/tools/SrvIface/**.exe
*/dll/*.ini
*/dll/*.exe
*/dll/*.dll
*/quux_obj/*
*.dbg
*~
scripts/backupPath.txt
*.local
*.orig
FooDoc/FooDoc/bin/*
FooDoc/FooDoc/FooDoc.suo
FooDoc/FooDoc/FooDoc.vbproj.user
FooDoc/FooDoc_Setup/Release
Foo/Engine/dll/FooObjects.pdb
Foo/Engine/dll/FooObjects.tlb
Foo/Engine/dll/FooObjects.xml
Foo/Engine/dll/InitechDebugTimer.txt
*.dsk
Foo/Engine/dll/Preferences/CustomToolbar.ini
Foo/Engine/Engine.~dsk
Foo/Engine/dll/ApplicationSettings.fooprefs
Foo/Engine/dll/Foo.cgl
Foo/Engine/dll/IniShare.mem
Foo/Engine/baz_obj/*
Foo/Engine/baz_pch/*
*/dll/*.drc
*.~dsk
InitechBaz/InitechBaz/bin/Debug/InitechBaz.vshost.exe.manifest
InitechBaz/InitechBaz/bin/Debug/InitechBaz.vshost.exe.config
InitechBaz/InitechBaz/bin/Debug/InitechBaz.vshost.exe
InitechBaz/InitechBaz/bin/Debug/InitechBaz.exe.config
scripts/TestComplete/Ottertech_Replay/Log/*
scripts/TestComplete/Ottertech_Replay/[*
relre:ReSharper*
relre:_UpgradeReport_Files
glob:*.suo
glob:*.pdb
*.swp
Foo/Engine/FooObjects/FooObjects/bin/x86/
FooDoc/MCtoDAT/MCtoDAT/bin/x86
FooDoc/Deploy
Foo/Engine/installers/initech-build/bin/*
scripts/TestComplete/Users/*
Foo/Engine/dll/MCtoDAT.xml
FooDoc/Deploy/*
scripts/TestComplete/Ottertech_Replay/Log/*
scripts/TestComplete/Ottertech_Replay/[*
*.orig
Foo/Engine/installers/icon-installers-bin/*
Foo/Engine/Quux/Server/*.esp
Foo/Engine/Quux/BrapServer/*.esp
Foo/Engine/installers/bin/*.exe
Foo/Engine/installers/quux/encryptedsql/*.esp
Foo/Engine/tools/tempfile.tmp
*.pch
*.#*
*.#??
Foo/Engine/dll/frabbing.lib
re:^.*\.\#[0-9][0-9]$
Foo/Engine/Foo/FooObjects/FooObjects/FooObjects.xml
FooDoc/MCtoDAT/MCtoDAT/MCtoDAT.xml
*.sln.cache
FooDoc/TestFooObj/TestFooObj/bin/
*.user
Foo/Engine/FooObjects/FooObjects/FooObjects.xml
Foo/Engine/FooObjects/FooObjects/FooObjects.xml
FooDoc/MCtoDAT/MCtoDAT/MCtoDAT.xml
*/Debug Installer/*.dll
*/Debug Installer/*.tlb
*/Debug Installer/*.xml
*/Debug Installer/*.msi
*/Debug Installer/*.exe
FooDoc/FooDoc_Setup/Debug/*
re:(?i).*\/UpgradeLog.xml
*.sln.cache
4

3 回答 3

3

通常在项目开始时忽略文件会发生一系列变化，但很快就会稳定下来。我猜你没有有效地使用通配符。如果您想不出在您的情况下如何使用通配符，您可能需要构建您的代码，以便新创建的被忽略的文件都进入一个目录。例如，将所有构建工件放入“构建”目录。这在您的构建脚本中需要更多的前期工作，但也有助于完成制表符之类的事情，因为您的源目录中只有源文件。

于 2011-10-13T18:17:42.550 回答
2

将 build-root移出repo-tree 并获取 builder 的源代码作为hg export. 这样你可以用一块石头杀死两只鸟

  • 构建对象不会在存储库中乱扔垃圾
  • 您可以验证所有需要的文件都在存储库中
于 2011-10-14T08:29:08.197 回答
0

像任何工具一样，Mercurial 只能走这么远。如前所述，大多数项目结构往往会在一段时间后稳定下来，这使得您的问题在标准用例中的相关性不如您自己的问题。

在你的情况下，很可能你只需要忍受这个。

一种替代方法是重组您的项目，使所有可忽略的文件位于同一位置，或者通过通配符模式引用。如果图片中唯一的力量是需要减轻忽视管理问题，我倾向于反对它。换句话说，您的源代码控制系统的特性或限制不应构成决定项目结构的力量。

也就是说，通常有真正的力量在努力产生稳定的项目结构，这些力量超越了源代码控制。例如，开发人员需要熟悉项目，而不断的变化会削弱熟悉度。显然不是你的情况，因为你有源代码被忽略。

我知道这对回答你的问题没有多大帮助，但我觉得问题出在源代码控制之外，并且在你的项目中，其他力量已经停止施加影响。

于 2011-10-20T14:12:29.913 回答