ฉันกำลังพิจารณาใช้ Git เพื่อจัดการห้องสมุด iTunes ของฉันและอนุญาตให้ฉันซิงค์ระหว่างคอมพิวเตอร์
คุณนึกถึงเหตุผลอะไรก็ได้ที่ทำให้ความคิดนี้แย่
ฉันกำลังพิจารณาใช้ Git เพื่อจัดการห้องสมุด iTunes ของฉันและอนุญาตให้ฉันซิงค์ระหว่างคอมพิวเตอร์
คุณนึกถึงเหตุผลอะไรก็ได้ที่ทำให้ความคิดนี้แย่
คำตอบ:
ข้อเสียเปรียบหลักคือพื้นที่ดิสก์ พื้นที่เก็บข้อมูลจะใช้พื้นที่จำนวนเท่ากับชุดของไฟล์ "เช็คเอาท์" ซึ่งหมายความว่าเมื่อคุณโคลนที่เก็บข้อมูลคอลเลกชันของคุณโดยทั่วไปจะใช้พื้นที่ดิสก์เป็นสองเท่า
ที่แย่กว่านั้นคือแม้ว่าคุณจะลบไฟล์ที่คุณไม่ต้องการอีกต่อไปก็จะยังมีการคัดลอกในพื้นที่เก็บข้อมูลของคุณซึ่งเป็นการเพิ่มพื้นที่
คุณอาจต้องการดูเครื่องมือการซิงโครไนซ์อย่างพร้อมเพรียงซึ่งออกแบบมาสำหรับการซิงโครไนซ์ไฟล์แบบสองทางในหลาย ๆ เครื่อง
คุณนึกถึงเหตุผลอะไรก็ได้ที่ทำให้ความคิดนี้แย่
Git ไม่เหมาะสมกับการใช้งานดังกล่าว
วิธีการทำงานของ git คือเก็บข้อมูลที่เก็บไว้ใน.git/โฟลเดอร์ ด้วยข้อความสิ่งนี้ไม่ใช่ปัญหาสามารถบีบอัดได้ง่ายและไฟล์มีขนาดเล็ก - ที่เก็บอาจเป็นเมกะไบต์หรือสองไฟล์
ข้อมูลที่บีบอัด (MP3, JPEGs ฯลฯ ) ไม่สามารถบีบอัดได้โดย git เพิ่มเติมและเนื่องจากคุณต้องการเก็บข้อมูลสองชุดอย่างมีประสิทธิภาพนี่จะเพิ่มพื้นที่ดิสก์เป็นสองเท่า (หนึ่งไฟล์สำหรับหนึ่งไฟล์สำหรับที่เก็บ)
ข้อความมีขนาดเล็กและสามารถบีบอัดได้และที่สำคัญคุณสามารถ "แตกต่าง" ได้อย่างง่ายดายระหว่างการแก้ไขสองครั้ง - เก็บเฉพาะการเปลี่ยนแปลง หากคุณเปลี่ยนเพียงหนึ่งบรรทัด git จะเก็บเพียงหนึ่งบรรทัดนั้นเท่านั้น (และข้อมูลเมตาที่เกี่ยวข้องเช่นข้อความคอมมิท)
ไฟล์ไบนารียากที่จะแตกต่างดังนั้นสมมติว่าคุณแก้ไขแท็กใน 100 ไฟล์ (เช่นเพิ่มงานศิลปะหรือเปลี่ยนประเภท) git จะเก็บสำเนาไฟล์ใหม่เหล่านั้นไว้ใน.git/ไดเรกทอรี สมมติว่าคุณลบความคิดเห็นทั้งหมดจากข้อมูลเมตาของเพลงของคุณแล้วคอมไพล์จะเก็บสำเนาไฟล์ของคุณอีกชุด! นี่จะหมายถึงที่เก็บของคุณจะมีขนาดใหญ่กว่าสองเท่าของไฟล์จริงของคุณ (บอกว่าคุณมีเพลง 10GB, โฟลเดอร์เพลงของคุณจะมากกว่า 30GB)
อย่างที่ฉันพูดไปแล้วคอมไพล์ไม่เหมาะกับสิ่งนั้น - มันมีจุดประสงค์เพื่อติดตามซอร์สโค้ดโดยมีการเปลี่ยนแปลงเล็กน้อยในไฟล์ข้อความไม่ใช่ไฟล์ไบนารี่ขนาดใหญ่ มีจุดไม่มากในการรักษาประวัติการแก้ไขของคลังเพลงของคุณเมื่อคุณต้องการเครื่องมือซิงค์
เนื่องจากคุณกำลังพิจารณาใช้ 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>
หากคุณใช้ระบบปฏิบัติการเดียวกันและชื่อผู้ใช้เดียวกันในทุกเครื่องนี่ไม่ใช่ปัญหา - เก็บไฟล์ในเส้นทางเดียวกันและควรใช้งานได้ดี ถ้าไม่สิ่งต่าง ๆ จะซับซ้อนขึ้นเล็กน้อย ..
คุณสามารถเขียนสองสคริปต์สคริปต์หนึ่งที่อัพเดตพา ธ จาก machineA ไปยัง machineB และในทางกลับกัน คุณสามารถย้ายคลัง iTunes ของคุณไปยังที่อื่นได้/User/Shared/Music/ดังนั้นเส้นทางจะเหมือนกัน (แม้ว่าวิธีนี้อาจใช้ไม่ได้กับ OS X -> Windows)
มีสาธารณูปโภคบางอย่างในการซิงค์คลัง iTunes ระหว่างเครื่องเช่น ..
(จากบทความนี้ )
ฉันไม่แน่ใจว่า Git มีปัญหากับขนาดไฟล์ในคลังเพลงหรือไม่ (มันทำงานได้ไม่ดีกับไฟล์ขนาดใหญ่ แต่ฉันไม่แน่ใจว่ามีขนาดใหญ่แค่ไหน) แต่ Joey Hess เขียนโปรแกรมที่เรียกว่าgit annexสำหรับ การจัดการกับกรณีการใช้งานประเภทนี้
ระบบควบคุมเวอร์ชันโดยทั่วไปออกแบบมาสำหรับการจัดการไฟล์ข้อความ ทุกครั้งที่คุณอัปเดตไฟล์ไบนารีจำเป็นต้องสร้างไฟล์ใหม่โดยสมบูรณ์ซึ่งต่างจากการจัดเก็บเดลต้า
สิ่งนี้แปลว่าเป็นการใช้งานจริงอย่างไรห้องสมุดของคุณจะใช้พื้นที่ดิสก์จำนวนมากหากคุณเปลี่ยนเป็นประจำ
หากคุณกำลังพูดถึงไฟล์ไลบรารีเองเท่านั้นอาจเป็นไปได้
ปัญหาอีกอย่างหนึ่งของการตั้งค่านี้คือ iTunes จัดเก็บฐานข้อมูลเป็นไฟล์ไบนารีที่เป็นกรรมสิทธิ์ซึ่ง git จะไม่สามารถทำการผสานได้ (ไม่การแก้ไขไฟล์ iTunes Music Library.xml จะไม่สามารถอ่านได้อีกครั้งโดย iTunes) . ดังนั้นหากคุณทำการเปลี่ยนแปลงข้อมูลเมตาหรือเพิ่มแทร็กเพิ่มเติมในทั้งสองเครื่องจะไม่มีวิธีที่จะกระทบยอดการเปลี่ยนแปลงที่เกิดขึ้นจากปลายทั้งสองคุณจะต้องเขียนทับฐานข้อมูลหนึ่งเวอร์ชันกับอีกอันหนึ่งและสูญเสียข้อมูลในกระบวนการ .
rsyncคุณอาจจะคิดของบางสิ่งบางอย่างมากขึ้นตามสายของ
ปัญหาพื้นที่ดิสก์ที่อธิบายไว้ข้างต้นเป็นจริงอย่างแน่นอน แต่มีสองปัญหาแยกกัน หนึ่งคือคุณต้องเก็บที่เก็บและข้อมูลดังนั้นแต่ละไฟล์จะถูกเก็บไว้ 2 ครั้ง ปัญหาที่สองคือทุกครั้งที่คุณเปลี่ยนข้อมูลเมตาของคุณสำเนาเพลงใหม่ทั้งหมดจะถูกเก็บไว้ดังนั้นคุณค่อย ๆ จบการจัดเก็บเพลงของคุณ N ครั้งโดยที่ N เพิ่มขึ้นอย่างต่อเนื่อง ปัญหาแรกอาจตกลงปัญหาที่สองคือการลากที่แท้จริง
ดังนั้นจึงเป็นเรื่องที่น่าสนใจว่าในขณะที่ Git ทนทุกข์ทรมานจากปัญหาที่สองการโค่นล้มไม่ได้ อัลกอริทึม diff ของมันทำงานกับไฟล์ไบนารีดังนั้นคุณจะเก็บเฉพาะการเปลี่ยนแปลงเท่านั้น นั่นเป็นเหตุผลที่ฉันใช้การโค่นล้มสำหรับภาพถ่ายของฉันคล้ายกับกรณีการใช้ของคุณและฉันมีความสุขมากกับมัน
นี่คือบันทึกที่แสดงถึงปัญหา โปรดทราบว่าการโค่นล้มจริงเก็บสามสำเนา: หนึ่งในพื้นที่เก็บข้อมูลหนึ่งในไดเรกทอรี. 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/
หากฉันจำได้ถูกต้องไลบรารีของ iTunes จะจัดเก็บตำแหน่งของเพลงเป็นเส้นทางแบบสัมบูรณ์ไม่สัมพันธ์กับไฟล์ไลบรารี สิ่งนี้จะทำให้เกิดปัญหาหากเพลงถูกจัดเก็บในตำแหน่งที่ต่างกันสองแห่งบนคอมพิวเตอร์