Git을 사용하여 iTunes 보관함을 관리 하시겠습니까? 동기화를 고려하고 있습니다. 이것이

Git을 사용하여 iTunes 보관함을 관리하고 컴퓨터 간 동기화를 고려하고 있습니다.

이것이 왜 나쁜 생각인지 생각할 수 있습니까?



답변

주요 단점은 디스크 공간입니다. 저장소 자체는 “체크 아웃 된”파일 세트와 동일한 공간을 차지합니다. 즉, 저장소를 복제 할 때 컬렉션은 기본적으로 두 배의 디스크 공간을 차지합니다.

더 나쁜 것은 더 이상 원하지 않는 파일을 삭제하더라도 저장소에 사본이 남아 공간을 차지한다는 것입니다.

여러 시스템에서 파일의 양방향 동기화를 위해 설계된 unison 과 같은 동기화 도구를 살펴볼 수 있습니다 .


답변

이것이 왜 나쁜 생각인지 생각할 수 있습니까?

Git은 이러한 용도에 적합하지 않습니다.

자식이 작동하는 방식은 저장소 데이터를 .git/폴더에 보관하는 것 입니다. 텍스트를 사용하면 문제가 아니며 쉽게 압축 할 수 있으며 파일이 작습니다. 리포지토리는 메가 바이트 또는 2 바이트 일 수 있습니다.

압축 된 데이터 (MP3, JPEG 등)는 git으로 더 이상 압축 할 수 없으며 두 개의 데이터 사본을 효과적으로 저장해야하므로 필요한 디스크 공간이 두 배가됩니다 (파일 하나, 저장소 하나)

텍스트는 작고 압축 가능하며 중요한 것은 두 수정본 사이를 쉽게 “확산”할 수 있다는 것입니다. 한 줄만 변경하면 git은 한 줄과 커밋 메시지와 같은 관련 메타 데이터 만 저장합니다.

이진 파일은 차이가 나기 때문에 100 개의 파일에서 태그를 수정 (예 : 아트 워크 추가 또는 장르 변경)하면 git은 해당 파일의 새 복사본을 해당 .git/디렉토리에 저장합니다. 그런 다음 음악의 메타 데이터에서 모든 주석을 제거하면 git이 파일의 다른 완전한 사본을 저장합니다! 즉, 저장소가 실제 파일 크기의 두 배가됩니다 (예 : 10GB의 음악이 있고 음악 폴더가 30GB를 초과 함).

내가 말했듯이 git은 그런 것들에 적합하지 않습니다-소스 파일을 추적하는 것을 목표로합니다. 큰 이진 파일이 아닌 텍스트 파일을 거의 변경하지 않았습니다. 동기화 도구가 필요할 때 음악 라이브러리의 개정 내역을 유지하는 데는 별다른 의미가 없습니다.

git 사용을 고려하고 있기 때문에 명령 줄 도구에 만족한다고 가정합니다. 따라서 rsync를 사용하여 iTunes 라이브러리를 컴퓨터간에 동기화하는 것이 좋습니다. joshhunt가 언급했듯이 가장 큰 문제는 iTunes가 미디어 파일의 절대 경로를 사용하므로 iTunes Library.xml파일에 다음과 같은 것들이 포함되어 있다는 것입니다.

<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>

모든 시스템에서 동일한 OS와 동일한 사용자 이름을 사용하는 경우 이는 문제가되지 않습니다. 파일을 동일한 경로에 유지하면 제대로 작동합니다. 그렇지 않으면 상황이 조금 더 복잡해집니다 ..

machineA에서 machineB 로의 경로를 업데이트하는 스크립트와 그 반대로 경로를 업데이트하는 두 개의 스크립트를 작성할 수 있습니다. /User/Shared/Music/경로가 동일하도록 iTunes 보관함을 다른 곳으로 옮길 수 있습니다 (OS X-> Windows에서는 작동하지 않을 수 있음)

다음과 같은 장비간에 iTunes 보관함을 동기화하는 유틸리티가 있습니다.

( 이 기사에서 )


답변

나는 확실하지 망할 놈의 음악 라이브러리에있는 파일의 크기에 문제가 있는지 여부를 해요 (이 큰 파일을 잘 수행하지 않습니다,하지만 나는 확실히 정확히 얼마나 큰 아니에요)하지만, 조이 헤스라는 프로그램 작성 자식 부속서 를 들어 이런 종류의 사용 사례를 다룹니다.


답변

버전 관리 시스템은 일반적으로 텍스트 파일을 처리하도록 설계되었습니다. 이진 파일을 업데이트 할 때마다 델타를 저장하는 대신 완전히 새로운 파일을 만들어야합니다.

이것이 실제 사용으로 변환되는 방법은 라이브러리를 정기적으로 변경하면 많은 디스크 공간을 사용한다는 것입니다.

라이브러리 파일 자체에 대해서만 이야기한다면 괜찮을 것입니다.


답변

이 설정의 또 다른 문제점은 iTunes가 데이터베이스를 독점 바이너리 파일로 저장하여 git에서 병합을 수행 할 수 없다는 것입니다 (iTunes Music Library.xml 파일에 대한 편집 내용은 iTunes에서 다시 읽을 수 없음) . 따라서 메타 데이터를 변경하거나 두 시스템에서 추가 트랙을 추가 한 경우 양쪽 끝에서 변경 한 내용을 조정할 방법이 없으므로 한 버전의 데이터베이스를 다른 버전으로 덮어 쓰고 프로세스에서 데이터를 잃게됩니다. .


답변

의 라인을 따라 더 많은 것을 생각하고있을 것입니다 rsync.


답변

위에서 설명한 디스크 공간 문제는 확실합니다. 그러나 두 가지 별도의 문제가 있습니다. 하나는 저장소와 데이터를 저장해야하므로 각 파일이 2 번 저장된다는 것입니다. 두 번째 문제는 메타 데이터를 변경할 때마다 완전히 새로운 음악 사본이 저장되므로 점차 음악을 N 번 저장하면 N이 계속 증가한다는 것입니다. 첫 번째 문제는 정상일 수 있고 두 번째 문제는 실제 문제입니다.

따라서 Git이 두 번째 문제로 어려움을 겪고 있지만 Subversion은 그렇지 않습니다. diff 알고리즘은 이진 파일에서 작동하므로 변경 내용 만 저장합니다. 그렇기 때문에 사진에 Subversion을 사용하는 이유는 사용 사례와 매우 유사하며 매우 만족합니다.

다음은 문제를 설명하는 로그입니다. Subversion은 실제로 저장소에 하나씩, 작업 사본에있는 .svn 디렉토리에있는 사본 및 작업 사본 자체의 세 사본을 저장합니다. 그러나 메타 데이터를 변경하면 추가 공간을 사용하지 않습니다.

mat@Winter:~/temp$ git init repo
Initialized empty Git repository in /home/mat/temp/repo/.git/
mat@Winter:~/temp$ cp -r light_and_magic/ repo/
mat@Winter:~/temp$ cd repo/
mat@Winter:~/temp/repo$ du -hs .
101M    .
mat@Winter:~/temp/repo$ git add light_and_magic/
mat@Winter:~/temp/repo$ git commit -m 'First commit'
...
mat@Winter:~/temp/repo$ du -hs .
191M    .
mat@Winter:~/temp/repo$ id3v2 -a 'ladytron' light_and_magic/*.mp3
mat@Winter:~/temp/repo$ git commit -a -m 'changed metadata'
...
 15 files changed, 0 insertions(+), 0 deletions(-)
mat@Winter:~/temp/repo$ du -hs .
282M    .
mat@Winter:~/temp$ svnadmin create repo
mat@Winter:~/temp$ svn co file:///home/mat/temp/repo working
Checked out revision 0.
mat@Winter:~/temp$ cp -r light_and_magic/ working/
mat@Winter:~/temp$ svn add working/light_and_magic/
...
mat@Winter:~/temp$ svn commit -m 'First commit' working/
...
mat@Winter:~/temp$ du -hs repo
91M     repo
mat@Winter:~/temp$ du -hs working/
201M    working/
mat@Winter:~/temp$ id3v2 -a 'ladytron' working/light_and_magic/*.mp3
mat@Winter:~/temp$ svn commit -m 'changed metadata' working/
...
mat@Winter:~/temp$ du -hs repo/
91M     repo/
mat@Winter:~/temp$ du -hs working/
201M    working/