협업을위한 버전 관리 (단어 수준 차이)?


20

대부분의 논문은 현재 공동으로 작성되며 공동 작업자는 종종 다른 장소에 있습니다. 필자는 항상 문서와 코드에 버전 제어 시스템을 사용해 왔으며 공동 작업 소프트웨어 프로젝트에 버전 제어가 중요하다는 사실을 발견했지만 이론적으로 많은 연구원들이 공동 논문 작성에 사용하지 않는 것 같습니다. 공동 작업자에게 버전 관리 (개정 제어)가 함께 작업하기에 좋은 아이디어임을 확신시키기 위해 몇 가지 전제 조건이있는 것 같습니다. 모든 사람이 줄 바꿈 및 단락에 대한 특정 규칙 집합에 대해 걱정하거나 탭 / 공간 변환을 피할 수는 없습니다.

누군가가 줄 수준이 아닌 단어 수준의 차이를 처리 할 수있는 텍스트 문서 용 버전 관리 기능을 통해 소규모 공유 문서 리포지토리의 무료 호스팅을 제공합니까 ?

그렇지 않다면 경험을 기반으로 한 다른 제안을 환영합니다 (추론을 피하십시오).

Git, Subversion, Mercurial, darcs 또는 Bazaar는 wdiff와 단어 수준의 차이를 처리하고 공개 키로 보호되는 액세스를 설정하는 간단한 방법 (예 : ssh를 통해)을 설정하도록 설정했습니다. 그러나 내가 본 버전 제어 공급자 중 어느 것도 이와 같은 것을 제공하지 않는 것 같습니다. 과학적 협업을 위해 많은 기업들이 강조한 "기업"기능은 그다지 중요하지 않습니다 (많은 지점, trac와의 통합, 타사의 감사, 계층 적 프로젝트 팀). 그러나 단어 수준의 차이는 중요하지만 지원되지 않는 것 같습니다. 필자의 경험에 따르면 텍스트 파일의 줄 수준 차이로 탭을 공백으로 변경하거나 그 반대로 문제를 일으키는 단락 및 편집기의 형식을 다시 지정하지 않아야합니다. 또한 가짜 편집 충돌이 많이있는 것 같습니다.

LaTeX 문서 용 버전 제어버전 제어용 LaTeX 패키지에 대한 협업 도구 및 TeX.SE의 관련 질문에 대해서는 MO의 관련 질문을 참조하십시오 . 주요 버전 제어 시스템 중 하나에 대한 대규모 호스팅 제공 업체 목록은 SVN 호스팅 비교 검토 차트 를 참조하십시오 .


편집 : TeX.SE 질문 " Subversion을위한 최고의 LaTeX 인식 diff 및 병합 도구 "에 대한 Jukka Suomela의 대답은 지금까지 단어 수준에서 델타를 해석하는 방법을 다루는 가장 좋은 제안 인 것 같습니다. 또한 Jukka는 리포지토리 끝의 후속 버전 간의 차이점이 충돌 감지 및 변경 병합에 사용되는 사용자 수준의 차이점과 어떻게 다른지 설명했습니다. TeX.SE의 Jukka의 답변은 편집 충돌을 피하기 위해 기존의 원자 편집 토큰에 의존하여 동시 편집 및 병합을 명시 적으로 제외합니다. 내 원래의 질문을 명확하게하고 수정하는 경우, 줄 차이가 아닌 단어 차이로 편집 충돌을 해결할 수있는 방법이 있습니까? 다시 말해wdiff또는 줄 끝의 차이와 공백의 차이를 무시할 수있는 방법과 유사한 유사한 도구가 버전 제어 도구 의 충돌 감지 부분에 통합되어 있습니까?


3
나는 그 질문을 이해하지 못한다. 예를 들어, SVN에서 사용자에게 표시되는 diff는 클라이언트에 의해 생성되며 SVN 클라이언트 (및 해당 구성)에 따라 단어 기반 diff 또는 라인 기반 diff를 얻습니다. SVN 저장소를 호스팅하는 회사는 이것에 전혀 영향을 미치지 않습니다.
Jukka Suomela

2
@suresh 텍스트 문서를 편집 (작성)하는 경우 누군가가 한 쉼표를 변경 한 것을보기 위해 diff로 한 줄 전체를 스캔해야하는 경우가 종종 있습니다. 올바른 동작은 일반적으로 최소 변경 단위를 표시하는 것입니다. 또는 누군가 줄 바꿈을 사용하지 않는 경우 동작을 고려하십시오. 그런 다음 한 단어를 변경하면 작은 변화를 찾을 수 있도록 전체 단락이 diff에 표시됩니다.
Mark Reitblatt

2
줄 바꿈을 위해 줄 바꿈을 사용하지 않습니다. 내 라텍스 소스 코드에서 실제 텍스트 줄은 일반적으로 전체 텍스트 단락입니다. 편집기는 현재 창 너비에 따라 표시하기 위해 자동 줄 바꿈 할 수 있습니다. 그것은 일을 많이 단순화시킵니다. 단락을 다시 줄 바꿈하거나 공동 저자와 "올바른"줄 너비에 동의해야하는 것에 대해 걱정할 필요가 없습니다. 그러나 변경 사항을 빠르게 보려면 단어 수준의 diff 도구가 필요합니다.
Jukka Suomela

2
@Andras 내 요점은 VC 시스템은 클라이언트 측에서 두 가지 개정 만 재구성 할 수 있어야한다는 것입니다. 놀랍게도 모든 VC 시스템이 그렇게 할 수있는 것은 아닙니다. 당신이 필요로하는 것은 단어 수준의 3 방향 병합 유틸리티이지만, 나는 모른다. 예를 들어 TortoiseMerge와 kdiff3은 모두 라인 기반입니다. 이러한 유틸리티가 있으면 외부 병합 유틸리티를 지정할 수있는 모든 VC 시스템으로 충분합니다. (그것은 svn, bzr, git, hg ...를 포함합니다)
Maverick Woo

3
혼동의 원인 중 하나는 SVN이 서버와 클라이언트 간 통신에 사용하고 서버가 내부적으로 저장소를 유지하는 데 사용하는 내장 이진 diff 알고리즘 (개별 바이트 수준에서 작동)이 있다는 것입니다 콤팩트. 이것은 단지 최적화 일뿐입니다. 사용자에게 보이지 않으며 동일한 이진 diff 알고리즘을 모든 종류의 파일에 적용 할 수 있습니다. 사용자가 볼 수있는 모든 것 (사람이 읽을 수있는 diff, 병합, 충돌 해결 ...)은 클라이언트 쪽에서 발생합니다.
Jukka Suomela

답변:


11

라텍스로 작성된 일부 문서에서 git을 사용하여 공동 작업했습니다. 몇 가지 규칙을 준수해야합니다.

  • 빈 줄이 없으면 라텍스는이 줄 바꿈을 무시합니다.
  • 서식에 동일한 구성 사용 (탭 / 공백 / 최대 텍스트 너비)
  • 최상의 결과를 얻으려면 리포지토리에 .gitattributes 파일을 만들고 행을 추가하십시오 *.tex diff=tex. 이것은 ff 구문을 인식하고 더 의미있는 출력으로 이어집니다.

그런 다음 사용 git diff --color-words하고 gitk --color-words(이 문서를 참조 단어의 차이를 볼 수 망할 놈의 단어 별 차이점 항상 로그 자식은 diff / 자식 표시하는 단어 사랑하는 알고리즘을 사용하는 방법을 구성하려면 자식에 대한 참조).

수동 병합을 줄이려면 섹션 및 하위 섹션에 별도의 파일을 사용하는 것이 좋습니다 (문서 크기에 따라 다름).


나는 내 자신의 문서를 위해 이것을하는 것을 고려할 것입니다. 내 목표의 대부분을 달성하는 쉬운 방법 인 것 같습니다. 하지만 모두가 ... 이런 식으로 일을 치열하다
안드라스 살 라몬

2
이 방법으로 주저하는 사람들을 위해 git 명령 줄이 마음에 들지 않으면 TortoiseGit을 사용할 수 있습니다. 새로운 텍스트 부분의 각 문장에 관한 것이지, 최대 텍스트 너비가없는 한 중요하지 않습니다. (나는 그 규칙없이 일부 프로젝트를 수행했습니다)
Davy

전반적으로, 나는 자식이 좋은 선택이라는 것에 동의합니다. 그러나 왜 (하위) 섹션에 대해 별도의 파일을 사용하여 수동 병합 횟수를 줄일 수 있습니까? 또한 새로운 문장에서 각 문장을 시작하는 것이 어떻게 도움이되는지 궁금합니다 (때로는 문장이 편집 과정에서 섞여 있음).
dd1

파일 분리에 관해서 : 그 당시에는 git merging의 정확한 세부 사항을 이해하지 못했기 때문에 실제로는 필요하지 않지만 다른 이유로 여전히 좋습니다. 새로운 줄의 문장은 매우 중요합니다 .git 주위의 대부분의 도구는 항상 줄 바꿈을 표시하므로 다른 전략을 사용하는 경우 편집자가 줄 바꿈을 수행하도록하십시오. 누군가 단락에서 1 단어를 변경할 때마다 사냥해야합니다 자동 병합의 경우에는 발생하지 않습니다.
Davy Landman 2013


4

나는 정말로 다른 사람들을 반향시키고 당신이 앉아서 멋진 SVN 전략을 세우기를 제안합니다. SVN을 사용하여 전체 "연구"구조를 호스팅합니다.

  • JabRef 참조 관리
  • 다운로드 한 PDF
  • 조항

그것은 모든 것을 포함하고 물론 역사를 제공하기 때문에 훌륭합니다. 경고는 자신의 서버가 필요하다는 것입니다. 그러나 기존의 Windows 컴퓨터 (또는 편안한 컴퓨터)가있는 경우 VisualSVN Server 를 통해 간단하게 설치할 수 있습니다 . 그런 다음 공동 작업자를위한 적절한 계정을 만들고 적절한 영역 (예 : JabRef bibtex 파일에 대한 읽기 액세스 및 공유중인 '진행중인'기사 영역에 대한 읽기 / 쓰기)에 대한 액세스 권한을 부여하십시오.

TortiseSVN 은 SVN과 상호 작용하기위한 Windows 클라이언트로 사용할 수 있습니다. 파일 이동 / 삭제 및 폴더 복사에주의해야합니다 (SVN은 각 폴더의 숨겨진 폴더에 메타 데이터를 저장하므로 SVN 내에서 delete 명령을 실행하여 제거해야합니다. 하지만 투자 할 가치가 있습니다).

그런 다음 공동 작업자와 작업 할 때 SVN도 사용해야합니다. 그러나 학습에 대한 투자는 가치가 없습니다. 그리고 일부 생각을 통해 jabref 파일에 대한 읽기 전용 액세스 권한을 가질 수 있습니다 (아마도 svn의 '외부'기능을 통해).

이런 식으로 약간의 생각과 약간의 노력으로 평소와 같이 문서를 편집하고, 매일 밤 변경 사항을 적용하고, 아침에 업데이트하고 모든 충돌을 쉽게 해결하는 상황에 처할 수 있습니다.

정말 추천합니다. 자신의 SVN을 설정하는 사람이 많을수록 향후 협업 옵션 만 개선되므로 더 좋을 것입니다 (물론 과학 저장소를 설정하는 '표준'방법이 있다면 유리할 것입니다).

-편집 : 사실, LaTeX 및 SVN과의 과학적 협업 전략에 대한 제안서를 작성했습니다 . svn externals 기능을 사용하여 비슷한 설정을 가진 사람들 간의 공동 작업을 쉽게 제안합니다 . 변경이 필요하거나 적절하지 않은 경우 알려주십시오.


4

위대한 게시물을 읽고 직접 솔루션을 찾고있는 동안 gitk에서 단어 수준의 변경 사항채색 하는 옵션을 발견했습니다 . 자동 완성 기능이 제공하지 않고 gitk 매뉴얼 페이지에 나열되지 않기 때문에 gitk 매개 변수는 새롭거나 문서화되지 않은 기능인 것 같습니다 .
내가 찾은 옵션은 다음과 같습니다.

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

"diff --color-words"gitk 검색하는 주제에 대한 여러 토론을 찾을 수 있습니다 .

편집 :
이것은 다음과 같습니다 ...

gitk를 사용하여 단어 수준에서 색상 차이


1

문제를 잘 이해하고 있습니다. git과 함께 diff에 만화경 을 사용하기 시작했습니다 . Mac 전용이지만 wdiff보다 성능이 뛰어나며 인터페이스 및 라이브 업데이트도 있습니다.


2
나에게 Kaleidoscope는 선 기반의 diff 도구 일뿐 아니라 각 줄 내부의 변경 사항을 강조 표시하는 것 같습니다. wdiff와 친구들을 대체하지 않습니다. 예를 들어, 텍스트의 단락을 취하고 줄 바꿈을 변경하면 만화경은 읽을 수없는 차이를 생성합니다. Wdiff 기반 도구는 줄 바꿈 변경 사항을 무시합니다.
Jukka Suomela
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.