উত্তর:
প্রধান ব্যর্থতা হ'ল ডিস্ক স্পেস। সংগ্রহস্থল নিজেই "চেক-আউট" ফাইলগুলির সেটের সমান পরিমাণ স্থান গ্রহণ করবে। এর অর্থ আপনি যখন সংগ্রহস্থলটিকে ক্লোন করেন তখন আপনার সংগ্রহটি মূলত ডিস্কের দ্বিগুণ স্থান গ্রহণ করবে।
সবচেয়ে খারাপ বিষয়, আপনি যদি আর ফাইলগুলি মুছতে না চান এমনকী, আপনার সংগ্রহস্থলে অনুলিপি থাকবে, স্থান গ্রহণ করবে।
আপনি একত্রীকরণের মতো সিঙ্ক্রোনাইজেশন সরঞ্জামগুলি দেখতে চাইতে পারেন যা একাধিক মেশিনে ফাইলের দ্বিমুখী সংলগ্নকরণের জন্য ডিজাইন করা হয়েছে।
কেন এটি কোনও খারাপ ধারণা হতে পারে তার কোনও কারণ সম্পর্কে আপনি ভাবতে পারেন?
গিট যেমন ব্যবহারের জন্য উপযুক্ত নয়।
গিটটি যেভাবে কাজ করে তা হ'ল এটি .git/ফোল্ডারে ভান্ডারগুলিকে রাখে । পাঠ্য সহ, এটি একটি নন-ইস্যু, এটি সহজেই সংকুচিত করা যায়, এবং ফাইলগুলি ছোট হয় - সংগ্রহস্থলটি মেগাবাইট বা দুটি হতে পারে।
সংকুচিত ডেটা (এমপি 3, জেপিইজি ইত্যাদি) আরও গিট দিয়ে সংকুচিত করা যায় না এবং যেহেতু আপনার কার্যকরভাবে ডেটার দুটি কপি সংরক্ষণ করতে হবে, এটি ডিস্ক-স্পেসের দ্বিগুণ করবে (ফাইলগুলির জন্য একটি, একটি সংগ্রহস্থলের জন্য একটি)
পাঠ্য ছোট এবং সংকোচযোগ্য এবং গুরুত্বপূর্ণ বিষয় আপনি দুটি সংশোধনীর মধ্যে সহজেই "পৃথক" করতে পারেন - কেবলমাত্র পরিবর্তনগুলি সংরক্ষণ করে। আপনি যদি কেবল একটি লাইন পরিবর্তন করেন তবে গিট কেবলমাত্র সেই লাইনটি সংরক্ষণ করে (এবং কোনও সম্পর্কিত মেটাডেটা, যেমন প্রতিশ্রুতি বার্তার মতো)
বাইনারি ফাইলগুলি পৃথক করা শক্ত, সুতরাং আপনি 100 ফাইলগুলিতে ট্যাগগুলি সংশোধন করে বলুন (বলুন, শিল্পকর্ম যুক্ত করতে বা একটি শৈলী পরিবর্তন করতে), গিটটি এই .git/ডিরেক্টরিতে এই ফাইলগুলির একটি নতুন অনুলিপি সঞ্চয় করবে । বলুন তারপরে আপনার সংগীতের মেটাডেটা থেকে সমস্ত মন্তব্য সরিয়ে ফেলুন, গিট তখন আপনার ফাইলগুলির আরও একটি সম্পূর্ণ অনুলিপি সঞ্চয় করবে! এর অর্থ হ'ল আপনার সংগ্রহস্থলটি এখন আপনার আসল ফাইলের আকারের দ্বিগুণ হবে (বলুন যে আপনার 10 গিগাবাইট সংগীত ছিল, আপনার সঙ্গীত ফোল্ডারটি এখন 30 গিগাবাইটের বেশি হবে)
যেমনটি আমি বলেছি, গিটটি এই জাতীয় জিনিসের সাথে উপযুক্ত নয় - এটি বৃহত বাইনারি ফাইল নয়, পাঠ্য ফাইলগুলিতে প্রচুর সামান্য পরিবর্তন সহ উত্স কোড ট্র্যাকিংয়ের লক্ষ্য। আপনার সংগীত লাইব্রেরির একটি পুনর্বিবেচনার ইতিহাস রাখার তেমন কোনও তাত্পর্য নেই, যখন আপনার সকলকে একটি সিঙ্কিং সরঞ্জাম প্রয়োজন।
যেহেতু আপনি গিটটি ব্যবহারের বিষয়ে বিবেচনা করছেন, আমি ধরে নিলাম আপনি কমান্ড লাইন সরঞ্জামগুলিতে যথেষ্ট খুশি, সুতরাং আমি মেশিনগুলির মধ্যে আপনার আইটিউনস লাইব্রেরি সিঙ্ক করতে rsync ব্যবহার করার পরামর্শ দেব। সবচেয়ে বড় সমস্যা, যেমন জোশান্ট উল্লেখ করেছেন, এটি আইটিউনস মিডিয়া ফাইলগুলির জন্য নিখুঁত পাথ ব্যবহার করে, সুতরাং iTunes Library.xmlফাইলটিতে এই জাতীয় জিনিস রয়েছে ...
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
আপনি যদি সমস্ত মেশিনে একই ওএস এবং একই ব্যবহারকারীর নাম ব্যবহার করেন তবে এটি একটি নন-ইস্যু - ফাইলগুলিকে একই পথে রাখুন এবং এটি ঠিকঠাক কাজ করা উচিত। যদি তা না হয় তবে বিষয়গুলি কিছুটা জটিল হয়ে যায় ..
আপনি দুটি স্ক্রিপ্ট লিখতে পারেন, একটি যা মেশিনএ থেকে মেশিনবিতে পাথ আপডেট করে এবং বিপরীতে। আপনি আপনার আইটিউনস লাইব্রেরিটিকে অন্য কোথাও স্থানান্তরিত করতে পারেন /User/Shared/Music/যাতে পাথগুলি একই থাকে (যদিও এটি ওএস এক্স -> উইন্ডোজের পক্ষে কাজ করে না)
আইটিউনস লাইব্রেরিগুলিকে মেশিনগুলির মধ্যে সিঙ্ক করার জন্য কয়েকটি ইউটিলিটি রয়েছে, যেমন ..
( এই নিবন্ধ থেকে )
আমি নিশ্চিত কিনা গীত একটি মিউজিক লাইব্রেরি ফাইলগুলির আকারের সঙ্গে সমস্যা রয়েছে আছি (এটা বড় ফাইল সঙ্গে ভাল সঞ্চালন করে না, কিন্তু আমি নিশ্চিত ঠিক কত বড় নই), কিন্তু জোয়ি হেস একটি প্রোগ্রাম নামক লিখেছেন Git অ্যানেক্স জন্য ব্যবহারের ক্ষেত্রে এই ধরণের সাথে ডিল।
সাধারণভাবে সংস্করণ নিয়ন্ত্রণ সিস্টেমগুলি পাঠ্য ফাইলগুলি পরিচালনা করার জন্য ডিজাইন করা হয়েছে। প্রতিবার বাইনারি ফাইল আপডেট করার সময় কেবল একটি ব-দ্বীপ সংরক্ষণ করার বিপরীতে সম্পূর্ণ নতুন ফাইল তৈরি করা দরকার।
এটি বাস্তব-বিশ্বের ব্যবহারে কীভাবে অনুবাদ করে তা হ'ল আপনি যদি নিয়মিতভাবে এটি পরিবর্তন করেন তবে আপনার গ্রন্থাগারটি প্রচুর ডিস্ক স্পেস ব্যবহার করবে।
আপনি যদি কেবল লাইব্রেরি ফাইলের কথা বলছেন তবে এটি ঠিক আছে।
এই সেটআপটির সাথে আরও একটি সমস্যা হ'ল আইটিউনস তার ডাটাবেসটিকে একটি মালিকানাধীন বাইনারি ফাইল হিসাবে সঞ্চয় করে যা গিটটি মার্জ করতে সক্ষম হবে না (না, আইটিউনস মিউজিক লাইব্রেরি.এক্সএমএল ফাইলগুলিতে সম্পাদনা আইটিউনস দ্বারা পুনরায় পাঠ করা যাবে না) । সুতরাং, যদি আপনি মেটাডেটাতে পরিবর্তন করেন বা উভয় মেশিনে অতিরিক্ত ট্র্যাক যুক্ত করেন তবে উভয় প্রান্ত থেকে করা পরিবর্তনগুলি পুনরায় মিলনের কোনও উপায় থাকবে না, আপনি অন্যটির সাথে ডাটাবেসের একটি সংস্করণ ওভাররাইট করে শেষ করবেন এবং প্রক্রিয়াটিতে ডেটা হারাবেন ।
উপরে বর্ণিত ডিস্ক জায়গার সমস্যাগুলি অবশ্যই সত্য। তবে দুটি আলাদা সমস্যা আছে। একটি হ'ল আপনাকে সংগ্রহস্থল এবং ডেটা সংরক্ষণ করতে হবে, তাই প্রতিটি ফাইল 2 বার সংরক্ষণ করা হয়। দ্বিতীয় সমস্যাটি হ'ল প্রতিবার আপনি যখন আপনার মেটাডেটা পরিবর্তন করবেন তখন সংগীতের পুরো একটি নতুন অনুলিপি সঞ্চিত হয়ে যায়, তাই ধীরে ধীরে আপনি আপনার সংগীত এন বারের সাথে সঞ্চয় করে শেষ করেন, যেখানে এন ক্রমাগত বৃদ্ধি পায়। প্রথম সমস্যাটি ঠিক থাকতে পারে, দ্বিতীয়টি আসল টান drag
সুতরাং এটি আকর্ষণীয় যে গিট যখন দ্বিতীয় সমস্যায় ভুগছেন তখনও সাবভার্সন হবেনা। এর পৃথক অ্যালগরিদম বাইনারি ফাইলগুলিতে কাজ করে, তাই আপনি কেবল পরিবর্তনগুলি সংরক্ষণ করেন। সে কারণেই আমি আমার ফটোগুলির জন্য সাবভারশন ব্যবহার করি যা আপনার ব্যবহারের ক্ষেত্রে খুব একই রকম এবং আমি এতে খুব খুশি।
এখানে একটি লগ যা সমস্যার চিত্র তুলে ধরে। দ্রষ্টব্য যে সাবভারশনটি আসলে তিনটি অনুলিপি সংরক্ষণ করে: একটি সংগ্রহস্থলীতে, একটি ওয়ার্কিং কপিতে .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/