Mercurial에서 끊임없이 .hgignore를 병합합니다.

Question

이것은 프로세스 질문이므로 여러 가지 정답이있을 수 있습니다. 나는 지금 가지고있는 것 이상의 무엇이든 가져갈 것이다.

우리 팀은 최근에 Mercurial (Subversion에서)을 사용하기로 전환했으며 대부분은 새로운 힘을 원합니다. 그러나 생산성을 감소시키는 몇 가지 사항이 있습니다. 그 중 하나는 .hgignore 파일을 관리하는 것입니다.

확립 된 문학 및 "인터넷에있는 일부 사용자"의 조언에 따라 이 항상 올바른 작업을 수행 할 수 있도록 .hgignore 파일을 최신 상태로 유지하고 있습니다. 또한 추가해야 할 누락 된 파일은 빌드 실패의 1 위 원인이므로 hg st은 진정한 조치가 필요한 파일 만 반환하는 것이 중요합니다.

문제는 항상 파일 맨 아래에 새로운 무시를 추가하기 때문에 두 사람이 .hgignore을 변경하면 항상 병합 충돌이 발생한다는 것입니다. (대부분의 사람들은 TortoiseHg 클라이언트를 사용하여 파일의 끝에 추가합니다.) 결과는 파일이 변경된 시간의 약 절반이 변경되었으므로 변경자는 .hgignore의 병합을 처리해야합니다. 이것은 우리 소스 컨트롤의 내부에 원숭이를 갖는 것과 매우 흡사합니다.

개발자는 최소한 012 분 동안 처리해야한다는 것을 알고 있으므로 .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 

Answer 1

일반적으로 프로젝트 시작시 ignore 파일에 갑작스런 변경이 발생하지만 상당히 빨리 정착합니다. 와일드 카드를 효과적으로 사용하지 않는 것 같습니다. 자신의 상황에서 와일드 카드를 사용하는 방법을 생각할 수 없다면 새로 작성된 무시 된 파일이 모두 하나의 디렉토리에 들어가도록 코드를 설계해야 할 것입니다. 예를 들어, 모든 빌드 아티팩트를 "빌드"디렉토리에 넣는 것입니다. 이는 빌드 스크립트에서 조금 더 앞선 작업이지만 소스 디렉토리에만 소스 파일이 있기 때문에 탭 완성과 같은 작업에 도움이됩니다.

Answer 2

build-root 외부에서 (repo-tree 외부)으로 이동하고 빌더에 대한 소스를 hg export의 결과로 가져옵니다.당신이

• 빌드 객체 저장소에없는 쓰레기는
• 당신은 어떤 도구처럼 저장소

Answer 3

에 이 것을 필요한 모든 파일을 확인할 수있는 것 일석이조 수있는이 방법 , Mercurial은 지금까지 갈 수 있습니다. 이전에 지적했듯이 대부분의 프로젝트 구조는 잠시 후 안정화되어 사용자의 문제보다는 표준 유스 케이스에서 관련성이 떨어집니다.

당신의 경우에, 당신은 단지 이것으로 살아야 할 수도 있습니다.

한 가지 대안은 무시할 수있는 모든 파일을 함께 배치하거나 달리 와일드 카드 패턴으로 참조 할 수 있도록 프로젝트를 재구성하는 것입니다. 사진 속의 유일한 힘이 관리 문제를 무시할 필요가 있다면 조언을하는 경향이 있습니다. 즉, 소스 제어 시스템의 특성이나 한계가 프로젝트 구조를 결정하는 데 영향을주지 않아야합니다.

즉, 일반적으로 안정적인 프로젝트 구조를 만들기 위해 노력하는 진정한 세력이 있으며 소스 제어를 넘어서는 세력이 있습니다. 예를 들어 개발자는 프로젝트에 익숙해야하며 일정한 변경은 친숙 함을 손상시킵니다. 소스 코드가 무시되는 것처럼 분명히 당신을위한 경우가 아닙니다.

나는 이것이 당신의 질문에 답하는 것에는 미치지 않을 것이라는 것을 안다. 그러나 문제는 소스 컨트롤 외부에 있으며 당신의 프로젝트에서 다른 힘들은 영향력을 행사하지 않는다고 느낀다.