Câu trả lời:
Hạn chế chính là không gian đĩa. Bản thân kho lưu trữ sẽ chiếm cùng một dung lượng như tập hợp các tệp "đã kiểm tra". Điều này có nghĩa là khi bạn sao chép kho lưu trữ, bộ sưu tập của bạn về cơ bản sẽ chiếm gấp đôi dung lượng đĩa.
Tệ hơn nữa, ngay cả khi bạn xóa các tệp bạn không còn muốn, vẫn sẽ có các bản sao trong kho lưu trữ của bạn, chiếm dung lượng.
Bạn có thể muốn xem các công cụ đồng bộ hóa như unison được thiết kế để đồng bộ hóa hai chiều các tệp trên nhiều máy.
Bạn có thể nghĩ ra bất kỳ lý do tại sao điều này sẽ là một ý tưởng tồi?
Git không phù hợp với việc sử dụng như vậy.
Cách git hoạt động là nó giữ dữ liệu kho lưu trữ trong .git/thư mục. Với văn bản, đây không phải là vấn đề, nó có thể được nén dễ dàng và các tệp nhỏ - kho lưu trữ có thể là một hoặc hai megabyte.
Dữ liệu nén (MP3, JPEG, v.v.) không thể được nén thêm bởi git và vì bạn thực sự cần lưu trữ hai bản sao của dữ liệu, điều này sẽ nhân đôi không gian đĩa cần thiết (một cho các tệp, một cho kho lưu trữ)
Văn bản rất nhỏ và có thể nén được và quan trọng là bạn có thể dễ dàng "khác biệt" giữa hai phiên bản - chỉ lưu trữ các thay đổi. Nếu bạn chỉ thay đổi một dòng, git chỉ lưu trữ một dòng đó (và bất kỳ siêu dữ liệu được liên kết nào, như thông điệp cam kết)
Các tệp nhị phân khó phân biệt, vì vậy, giả sử bạn sửa đổi các thẻ trên 100 tệp (giả sử để thêm tác phẩm nghệ thuật hoặc thay đổi thể loại), git sẽ lưu trữ một bản sao mới của các tệp đó trong .git/thư mục của nó . Giả sử bạn sau đó loại bỏ tất cả các nhận xét từ siêu dữ liệu âm nhạc của bạn, git sau đó sẽ lưu trữ một bản sao hoàn chỉnh khác của các tệp của bạn! Điều này có nghĩa là kho lưu trữ của bạn bây giờ sẽ lớn hơn gấp đôi kích thước của các tệp thực tế của bạn (giả sử bạn có 10GB nhạc, thư mục nhạc của bạn bây giờ sẽ trên 30 GB)
Như tôi đã nói, git không phù hợp với những thứ như vậy - nó nhằm mục đích theo dõi mã nguồn, với rất nhiều thay đổi nhỏ đối với tệp văn bản, không phải tệp nhị phân lớn. Không có nhiều điểm trong việc lưu giữ lịch sử sửa đổi của thư viện nhạc của bạn, khi tất cả những gì bạn cần là một công cụ đồng bộ hóa.
Vì bạn đang cân nhắc sử dụng git, tôi cho rằng bạn đã đủ hài lòng với các công cụ dòng lệnh, vì vậy tôi khuyên bạn nên xem xét sử dụng rsync để đồng bộ thư viện iTunes giữa các máy. Vấn đề lớn nhất, như joshhunt đã đề cập, iTunes sử dụng các đường dẫn tuyệt đối đến các tệp phương tiện, vì vậy iTunes Library.xmltệp chứa những thứ như ..
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
Nếu bạn sử dụng cùng một hệ điều hành và cùng tên người dùng trên tất cả các máy thì đây không phải là vấn đề - hãy giữ các tệp trong cùng một đường dẫn và nó sẽ hoạt động tốt. Nếu không, mọi thứ sẽ phức tạp hơn một chút ..
Bạn có thể viết hai tập lệnh, một tập lệnh cập nhật các đường dẫn từ machineA đến machineB và ngược lại. Bạn có thể di chuyển Thư viện iTunes của mình đến một nơi nào đó giống như /User/Shared/Music/vậy để các đường dẫn giống nhau (mặc dù điều này có thể không hoạt động cho OS X -> Windows)
Có một số tiện ích để đồng bộ Thư viện iTunes giữa các máy, chẳng hạn như ..
(từ bài viết này )
Các hệ thống kiểm soát phiên bản nói chung được thiết kế để xử lý các tệp văn bản. Mỗi khi bạn cập nhật một tệp nhị phân, nó cần tạo một tệp hoàn toàn mới thay vì chỉ lưu trữ một delta.
Làm thế nào điều này chuyển sang sử dụng trong thế giới thực là thư viện của bạn sẽ sử dụng nhiều dung lượng đĩa nếu bạn thay đổi nó thường xuyên.
Nếu bạn chỉ nói về chính tệp thư viện, điều này có thể ổn.
Một vấn đề nữa với thiết lập này là iTunes lưu trữ cơ sở dữ liệu của nó dưới dạng tệp nhị phân độc quyền mà git sẽ không thể thực hiện hợp nhất trên (không, chỉnh sửa tệp iTunes Music Library.xml sẽ không được đọc lại bởi iTunes) . Vì vậy, nếu bạn đã thay đổi siêu dữ liệu hoặc thêm các bản nhạc bổ sung trên cả hai máy, sẽ không có cách nào để điều hòa các thay đổi được thực hiện từ cả hai đầu, cuối cùng bạn sẽ ghi đè lên một phiên bản của cơ sở dữ liệu với phiên bản kia và mất dữ liệu trong quá trình .
Các vấn đề không gian đĩa được mô tả ở trên là chắc chắn đúng. Nhưng có hai vấn đề riêng biệt. Một là bạn phải lưu trữ kho lưu trữ và dữ liệu, vì vậy mỗi tệp được lưu trữ 2 lần. Vấn đề thứ hai là mỗi khi bạn thay đổi siêu dữ liệu của mình, một bản sao hoàn toàn mới của âm nhạc sẽ được lưu trữ, do đó dần dần bạn sẽ lưu trữ nhạc của mình N lần, trong đó N liên tục tăng. Vấn đề đầu tiên có thể ổn, vấn đề thứ hai là một lực cản thực sự.
Vì vậy, thật thú vị khi Git gặp phải vấn đề thứ hai, Subversion thì không. Thuật toán diff của nó hoạt động trên các tệp nhị phân, vì vậy bạn chỉ lưu trữ những gì thay đổi. Đó là lý do tại sao tôi sử dụng Subversion cho ảnh của mình, rất giống với trường hợp sử dụng của bạn và tôi rất hài lòng với nó.
Đây là một bản ghi minh họa vấn đề. Lưu ý rằng Subversion thực sự lưu trữ ba bản sao: một trong kho lưu trữ, một trong các thư mục .svn trong bản sao làm việc và bản sao làm việc. Tuy nhiên, nó không sử dụng bất kỳ không gian bổ sung nào khi tôi thay đổi siêu dữ liệu.
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/