जवाबों:
मुख्य दोष डिस्क स्थान है। रिपॉजिटरी अपने आप में "चेक-आउट" फ़ाइलों के सेट के समान स्थान ले लेगी। इसका मतलब यह है कि जब आप रिपॉजिटरी को क्लोन करते हैं तो आपका संग्रह मूल रूप से दोगुना डिस्क स्थान लेगा।
इससे भी बदतर, भले ही आप ऐसी फ़ाइलों को हटा दें जिन्हें आप नहीं चाहते हैं, फिर भी आपकी रिपॉजिटरी में जगह लेने के बाद भी प्रतियां होंगी।
आप यूनिसन जैसे सिंक्रोनाइज़ेशन टूल को देखना चाहते हैं जो कई मशीनों में फ़ाइलों के दो-तरफ़ा सिंक्रनाइज़ेशन के लिए डिज़ाइन किया गया है।
क्या आप किसी भी कारण के बारे में सोच सकते हैं कि यह एक बुरा विचार क्यों होगा?
Git ऐसे उपयोग के लिए उपयुक्त नहीं है।
जिस तरह से यह काम करता है वह .git/फ़ोल्डर में रिपॉजिटरी डेटा रखता है । पाठ के साथ, यह एक गैर-मुद्दा है, इसे आसानी से संपीड़ित किया जा सकता है, और फाइलें छोटी हैं - रिपॉजिटरी मेगाबाइट या दो हो सकती है।
संपीड़ित डेटा (MP3s, JPEGs आदि) को git द्वारा आगे संकुचित नहीं किया जा सकता है, और चूंकि आपको प्रभावी रूप से डेटा की दो प्रतियां संग्रहीत करने की आवश्यकता है, यह डिस्क-स्पेस को दोगुना कर देगा (एक फ़ाइलों के लिए, एक रिपॉजिटरी के लिए)
पाठ छोटा, और संकुचित करने योग्य है, और महत्वपूर्ण रूप से आप आसानी से दो संशोधनों के बीच "अंतर" कर सकते हैं - केवल परिवर्तनों को संग्रहीत करना। यदि आप केवल एक पंक्ति बदलते हैं, तो केवल उस पंक्ति को संग्रहीत करें (और किसी भी संबंधित मेटाडेटा, जैसे कि प्रतिबद्ध संदेश)
द्विआधारी फ़ाइलों को अलग करना मुश्किल है, इसलिए कहते हैं कि आप 100 फाइलों पर टैग को संशोधित करते हैं (कहते हैं, कलाकृति को जोड़ना, या एक शैली बदलना), git उन फ़ाइलों की एक नई प्रतिलिपि .git/निर्देशिका में संग्रहीत करेगा । फिर आप कहेंगे कि आपके संगीत के मेटाडेटा से सभी टिप्पणियाँ निकाल दें, तो git आपकी फ़ाइलों की एक और पूरी प्रतिलिपि संग्रहीत करेगा! इसका मतलब है कि आपकी रिपॉजिटरी अब आपकी वास्तविक फ़ाइलों के आकार से दोगुनी हो जाएगी (जैसे कि आपके पास 10GB संगीत था, आपका संगीत फ़ोल्डर अब 30GB से अधिक होगा)
जैसा कि मैंने कहा था, git ऐसी चीजों के अनुकूल नहीं है - इसका उद्देश्य स्रोत कोड पर नज़र रखना है, जिसमें बहुत सी पाठ फ़ाइलों में बहुत कम परिवर्तन होते हैं, न कि बड़ी बाइनरी फाइलें। आपके संगीत पुस्तकालय के पुनरीक्षण इतिहास को ध्यान में रखते हुए, जब आप सभी को एक सिंकिंग टूल की आवश्यकता होती है, तो बहुत ज्यादा मायने नहीं रखते हैं।
चूंकि आप गिट का उपयोग करने पर विचार कर रहे हैं, मुझे लगता है कि आप कमांड लाइन टूल के साथ काफी खुश हैं, इसलिए मैं मशीनों के बीच अपने आईट्यून्स लाइब्रेरी को सिंक करने के लिए rsync का उपयोग करने का सुझाव दूंगा। सबसे बड़ी समस्या, जैसा कि joshhunt ने उल्लेख किया है, iTunes मीडिया फ़ाइलों के लिए पूर्ण पथ का उपयोग करता है, इसलिए iTunes Library.xmlफ़ाइल में चीजें शामिल हैं ..
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
यदि आप सभी मशीनों पर एक ही OS, और एक ही उपयोगकर्ता नाम का उपयोग करते हैं, तो यह एक गैर-मुद्दा है - फ़ाइलों को उसी पथ पर रखें और यह ठीक काम करेगा। यदि नहीं, तो चीजें थोड़ी अधिक जटिल हो जाती हैं।
आप दो स्क्रिप्ट लिख सकते हैं, एक जो मशीनए से मशीनबी तक के रास्तों को अपडेट करता है, और इसके विपरीत। आप अपनी iTunes लाइब्रेरी को कहीं स्थानांतरित कर सकते हैं जैसे /User/Shared/Music/कि पथ समान हैं (हालांकि यह OS X -> विंडोज के लिए काम नहीं कर सकता है)
आइट्यून्स पुस्तकालयों को मशीनों के बीच सिंक करने के लिए कुछ उपयोगिताओं हैं, जैसे कि ।।
( इस लेख से )
मुझे यकीन है कि नहीं है कि क्या Git एक संगीत पुस्तकालय में फ़ाइलों के आकार के साथ समस्या है कर रहा हूँ (यह बड़ी फ़ाइलों के साथ अच्छा प्रदर्शन नहीं करता है, लेकिन मुझे यकीन है कि वास्तव में कितनी बड़ी नहीं कर रहा हूँ), लेकिन जॉय हेस एक कार्यक्रम बुलाया लिखा था Git चयक के लिए इस तरह के उपयोग के मामले से निपटना।
सामान्य रूप से संस्करण नियंत्रण प्रणाली को पाठ फ़ाइलों को संभालने के लिए डिज़ाइन किया गया है। हर बार जब आप किसी बाइनरी फ़ाइल को अपडेट करते हैं, तो उसे केवल एक डेल्टा स्टोर करने के विपरीत एक पूरी तरह से नई फ़ाइल बनाने की आवश्यकता होती है।
यह वास्तविक दुनिया के उपयोग के लिए कैसे अनुवाद करता है अगर आप इसे नियमित रूप से बदलते हैं तो आपका पुस्तकालय बहुत सारे डिस्क स्थान का उपयोग करेगा।
यदि आप केवल लाइब्रेरी फ़ाइल के बारे में बात कर रहे हैं, तो यह ठीक हो सकता है।
इस सेटअप के साथ एक और समस्या यह है कि आईट्यून्स अपने डेटाबेस को एक मालिकाना बाइनरी फ़ाइल के रूप में संग्रहीत करता है जो गिट पर विलय करने में सक्षम नहीं होगा (नहीं, आईट्यून्स म्यूज़िक लाइब्रेरी के लिए संपादन करता है। एक्सएमएल फ़ाइल को आईट्यून्स द्वारा वापस नहीं पढ़ा जाएगा) । इसलिए, यदि आपने मेटाडेटा में परिवर्तन किया है या दोनों मशीनों पर अतिरिक्त ट्रैक जोड़े हैं, तो दोनों सिरों से किए गए परिवर्तनों को सामंजस्य करने का कोई तरीका नहीं होगा, आप डेटाबेस के एक संस्करण को दूसरे के साथ अधिलेखित कर देंगे और प्रक्रिया में डेटा खो देंगे। ।
ऊपर वर्णित डिस्क स्थान की समस्याएं निश्चित रूप से सच हैं। लेकिन दो अलग-अलग समस्याएं हैं। एक यह है कि आपको रिपॉजिटरी और डेटा स्टोर करना होगा, इसलिए प्रत्येक फ़ाइल 2 बार संग्रहीत की जाती है। दूसरी समस्या यह है कि हर बार जब आप अपने मेटाडेटा को बदलते हैं तो संगीत की एक पूरी नई प्रति संग्रहीत हो जाती है, इसलिए धीरे-धीरे आप अपने संगीत को एन बार स्टोर करते हैं, जहां एन लगातार बढ़ता है। पहली समस्या ठीक हो सकती है, दूसरी वास्तविक ड्रैग है।
इसलिए यह दिलचस्प है कि जबकि Git दूसरी समस्या से ग्रस्त है, लेकिन तोड़फोड़ नहीं करता है। इसका अलग एल्गोरिथ्म बाइनरी फाइलों पर काम करता है, इसलिए आप केवल वही परिवर्तन संग्रहीत करते हैं। इसलिए मैं अपनी तस्वीरों के लिए तोड़फोड़ का उपयोग करता हूं, आपके उपयोग के मामले के समान है, और मैं इससे बहुत खुश हूं।
यहाँ एक लॉग है जो समस्या का चित्रण करता है। ध्यान दें कि सबवर्सन वास्तव में तीन प्रतियों को संग्रहीत करता है: एक रिपॉजिटरी में, एक वर्किंग कॉपी में .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/