답변:
한 파일과 다른 파일을 비교하는 것보다 차이점이 더 복잡 할 수 있습니다. 전체 디렉토리 계층을 비교할 수 있습니다. GCC의 버그를 수정하려는 예를 고려하십시오. 변경하면 4 개 또는 5 개의 파일에 한두 줄이 추가되고 해당 파일과 다른 파일에서 몇 줄이 삭제됩니다. 이 변경 사항을 누군가에게 알리고 싶다면 GCC에 포함될 가능성이 있습니다.
전체 소스 트리를 복사하는 것은 의미가 없지만 질문의 핵심 인 다른 두 가지 옵션은 어떻습니까? 이제 다른 사람도 내가했던 것과 같은 파일을 작업했으며 둘 다 누군가에게 변경 사항을 제공한다고 생각하십시오. 이 사람은 우리가 한 일과 변경 사항이 호환되는지 (파일의 다른 부분) 또는 충돌하는지 (파일의 동일한 줄) 어떻게 알 수 있습니까? 그는 그들을 모으게 될 것이다! diff는 파일이 어떻게 서로 다르고 수정되지 않은 소스 파일과 다른지 알려줄 수 있습니다. diff가 필요한 경우 diff를 먼저 보내는 것이 더 합리적입니다. diff에는 둘 이상의 파일의 변경 사항도 포함될 수 있으므로 총 9 개의 파일을 편집하는 동안 해당 변경 사항을 설명하는 단일 diff 파일을 제공 할 수 있습니다.
Diff를 사용하여 기록을 제공 할 수도 있습니다. 3 개월 전에 변경으로 오늘 발견 한 버그가 발생한 경우 어떻게됩니까? 버그가 소개 될 때 범위를 좁히고 특정 변경으로 분리 할 수 있으면 diff를 사용하여 변경을 "실행 취소"하거나 되돌릴 수 있습니다. 파일을 복사하는 것만 큼 쉽게 할 수있는 일은 아닙니다.
이것은 프로그램이 파일 히스토리를 작성 시점부터 현재까지 일련의 차이로 기록 할 수있는 소스 버전 제어와 관련이 있습니다. diff는 히스토리를 제공합니다 (파일을 특정 요일에 있던 것처럼 다시 만들 수 있음). 누가 다른 것을 깨뜨린 것에 대해 책임을 져야 할지를 볼 수 있으며 (diff는 소유자가 있음) 특정 diff를 제공하여 업스트림 프로젝트에 변경 사항을 쉽게 제출할 수 있습니다 어쩌면 그들은 내가 많은 것을 만들었을 때 하나의 변화에만 관심이있을 것입니다).
요약하면, 그래, cp보다 쉽게 diff하고 patch, 그러나의 유용성 diff과 patch보다 큰 cp파일의 변화를 추적하는 것이 중요 얼마나 상황.
패치를 받으면 자주 (같은 줄을 변경하지 않은 한) 패치를 자신이 변경 한 파일 세트에 적용 할 수 있습니다.
패치에는 파일 의 이전 상태 와 새로운 상태에 대한 정보가 있습니다. 복사 된 파일을 얻는 경우 원본이 무엇인지 (이전 상태) 알지 못하고 큰 어려움없이 변경 한 파일 (또는 파일 세트)에 차이를 적용 할 수 없습니다. 따라서 소스 파일 세트의 경우 중요한 관심사 인 공간 보존이 아니라 이전 정보입니다.
(문맥 / 통일) diffs 이전에는 편집자 (X 뒤에 행 삽입, Y 행 삭제)에 대한 지시 사항을 사용하여 수행되었지만, 이러한 명령이 시작된 상태를 알고있는 경우에만 작동합니다. 따라서 복사 만하면 "솔루션"과 동일한 문제가 발생합니다.
diff -u)는 인간을 위해 설계된 개선이며, 규칙적인 상황 차이 ( diff -c) 에 대한 갈등에 대한 견고성을 돕지 못한다고 생각합니다. 심지어 일반 diff ( diff) 조차도 종종 "이 명령이 시작된 상태"를 정확히 모르고도 여전히 작동합니다. 그럼에도 불구하고 패치 파일이 여러 소스 파일을 동시에 패치 할 수있는 방법에 대한 이야기는 실제로 청어입니다.
파일에 대한 변경 사항은 일반적으로 변경되는 파일보다 훨씬 작습니다.
이것은 diff를 저장하면 많은 공간을 절약 할 수 있음을 의미합니다. diff만들어 졌을 때 디스크 공간이 비쌌습니다.
그러나 파일이 다른 방식으로 변경된 경우에도 파일에 diff를 다시 적용 할 수 있음을 의미합니다. 패치 유틸리티는 당신을 위해 그렇게 문제가있을 때 당신에게 말할 것이다.
이것이 실제로 소프트웨어 개발에서 차이점을 다루는 가장 중요한 이유입니다. 변경이 이루어지면 (보통 둘 이상의 파일로) diff로 저장할 수 있습니다. 결과를 변경 세트 또는 패치 라고 합니다 . 모든 것이 잘된다면, 패치는 단지 임의의 변경이 아니라 버그 수정 또는 새로운 기능과 같은 일종의 기능적 변경을 구현합니다.
한편, 다른 위치에서도 다른 개발자에 의해 다른 변경이 이루어질 수 있습니다. 동일한 파일의 동일한 부분을 변경하지 않은 경우 독립적으로 적용 할 수 있습니다. 따라서 개발자는 테스트를 위해 서로 패치를 보낼 수 있습니다. 가능한 변경 사항을 나타내는 전체 패치 세트가 구축 될 수 있습니다. 이 중 일부는 거부 될 수 있으며 나머지는 시스템에 통합됩니다.
diff를 사용하면 동시 개발이 가능합니다. 더 이상 한 번에 하나의 변경 작업을 수행 할 필요가 없습니다.
최신 분산 버전 제어 시스템은 이러한 작업 방식의 연속입니다.
한마디로 할 수 있습니다. YouTube에서 Thinkg Big Larry Wall 비디오를 보면 diff / patch가 시작된 방법과 해결 된 문제에 대해 이야기하며, 본질적으로 패치를 유연하고 사람이 읽을 수있게 유지하면서 인터넷을 통한 통신의 크기를 줄이는 것이 었습니다. .
로컬 시스템에이고 할 경우, 이러한 것들의 걱정하지 cp또는 rsync정상입니다.