চিত্রগুলি কি গিটের ভাণ্ডারে সংরক্ষণ করা উচিত?


200

বিতরণকারী টিমের জন্য যা গিট এবং গিথুবকে সংস্করণ নিয়ন্ত্রণ হিসাবে ব্যবহার করে, চিত্রগুলিও কি গিট সংগ্রহস্থলে সংরক্ষণ করা উচিত?

বেশিরভাগ ক্ষেত্রে, চিত্রগুলি পরিবর্তন করা হবে না। এগুলি যুক্ত ফোল্ডারটি চিত্র যুক্ত হওয়ার সাথে সাথে আকারে বৃদ্ধি পাবে। উদ্বেগের বিষয় হ'ল চিত্রের ফোল্ডারটি বড় চিত্রগুলির সংমিশ্রণে বা তাদের মধ্যে অনেকগুলি সংখ্যক সময়ের সাথে বড় আকারে বাড়তে পারে।

এটাকে কি সেরা অনুশীলন বলে মনে করা হয়? বিতরণকারী দল সহজেই অ্যাক্সেস করতে পারে এমন প্রকল্পগুলিতে বাইনারি ফাইলগুলি ভাগ করে নেওয়ার আরও কী বিকল্প রয়েছে?


17
আপনি যখন "চিত্রগুলি" বলছেন আমরা কি 26 এমবি ডিএসএলআর কাঁচা ফাইল, 1 এমবি 3 ডি গেম টেক্সচার, বা <100 কে পিএনজি আইকনগুলির বিষয়ে কথা বলছি? (আমি "এটি নির্ভর করে" এর উত্তর দিতে যাচ্ছিলাম তবে আমি বিরত থাকব)
ব্রুক

2
@ ব্রুক: আমি ধরণের অনুমান করেছি যে আমরা ওয়েবসাইটগুলির জন্য আইকন বা ছোট গ্রাফিক উপাদানগুলি বলছিলাম। গেম টেক্সচার, গ্রাফিক ডিজাইনের কাঁচা ফাইল বা ডকুমেন্টেশন এডিটিংয়ের জন্য সঠিক গ্রাফিক্স আলাদা গল্প হতে পারে, আপনি ঠিক বলেছেন।
হাইলেম

6
আমি ব্যক্তিগতভাবে ভেবেছিলাম সে ছবি মানেই নয়, আইএসও ইমেজ বোঝায়।
মাহমুদ হোসাম

2
এটি সত্যই ছোট / মাঝারি আকারের ওয়েব-বান্ধব চিত্রগুলির জন্য হওয়া উচিত। উদ্বেগের বিষয় হ'ল কিছু দেব-স্বাক্ষরকারীরা সেখানে প্রতিটি বড় মূল চিত্রকে স্টিক করা শুরু করবে, যখন আমি ভাবছি যে সম্ভবত অন্য কিছু ব্যবহার করা উচিত।
spong

6
আজ এই প্রশ্ন পড়া? গিট এলএফএস-এর নীচে উত্তরটি দেখুন। এটি সম্ভবত আপনি চান। প্রোগ্রামার্স.স্ট্যাক্কেঞ্জেন্জ.এ
303082/982506

উত্তর:


188

আপনার চিত্রগুলি কি আসল কাজ বা এগুলি অন্য কোথাও থেকে পুনরুদ্ধার করা (গ্যারান্টিযুক্ত?) করা যেতে পারে? তাদের উত্স থেকে নির্মিত একটি সফ্টওয়্যার ইউনিট শিপিং করা প্রয়োজন? এগুলি যদি আসল হয় তবে তাদের ব্যাক আপ নেওয়া দরকার। এগুলি আপনার পুনর্বিবেচনার নিয়ন্ত্রণে রাখুন, যদি তারা কখনও পরিবর্তন না হয় তবে স্পেস পেনাল্টিটি ব্যাকআপের মতোই এবং আপনার যেখানে প্রয়োজন সেখানে তারা।

এগুলি দুর্ঘটনাক্রমে বা ইচ্ছাকৃতভাবে সফ্টওয়্যারটির উপস্থিতি পরিবর্তনের জন্য সম্পাদনা করা যেতে পারে? হ্যাঁ - তারপরে এগুলি অবশ্যই কোনওভাবে পুনর্বিবেচনা নিয়ন্ত্রিত হওয়া উচিত, যখন আপনার ইতিমধ্যে একটি নিখুঁত সমাধান রয়েছে তখন কেন অন্য উপায় ব্যবহার করুন। অন্ধকার যুগ থেকে সংস্করণ নিয়ন্ত্রণ কেন "অনুলিপি এবং পুনর্নামকরণ" প্রবর্তন করবেন?

গ্রাফিক্স ডিজাইনারের ম্যাকবুক হার্ড ড্রাইভ মারা যাওয়ার পরে আমি পুরো প্রকল্পের মূল শিল্পকর্মটি "poof" দেখেছি, কারণ অসীম জ্ঞানের দ্বারা কেউ সিদ্ধান্ত নিয়েছে যে "বাইনারিগুলি রেভ নিয়ন্ত্রণে আসে না", এবং গ্রাফিক্স ডিজাইনার (কমপক্ষে এটি একটি ) ব্যাকআপ সঙ্গে ভাল হতে ঝোঁক না।

উপরোক্ত মানদণ্ডের মাপসইযুক্ত যে কোনও এবং সমস্ত বাইনারি ফাইলগুলিতে একই প্রয়োগ হয়।

ডিস্ক স্পেস না করার একমাত্র কারণ। আমি ভয় পাচ্ছি $ 100 / টেরাবাইট, এই অজুহাতটি কিছুটা পাতলা হয়েছে।


44
বিটিডাব্লু: ইন্টারনেট কোনও নির্ভরযোগ্য উত্স নয়। আপনি যদি "bobsfreestuff.com" থেকে কোনও চিত্র ডাউনলোড করেন তবে সম্ভবত এটি পরের সপ্তাহে হবে না।
mattnz

16
+1 - এবং আরও বেশি হওয়া উচিত। সংস্করণ নিয়ন্ত্রণের বিন্দুটি হ'ল কিছু অতীত সময়, স্টাফ যা-ই হোক না কেন, পুনরায় পুনরুদ্ধার / ফেরত আনতে দেওয়া। ১০০% হওয়ার একমাত্র উপায় যে আপনি প্রতিটি জিনিসটিকে সংস্করণ নিয়ন্ত্রণে রাখার সময়ে সেই সময়ে যা হওয়ার কথা ছিল তা ফিরে পেতে পারেন। Thats উত্স, চিত্র, পুনরায় স্থান, সহায়তাফুল / সমর্থনকারী পিডিএফ। হেক, আমি এমনকি জিপড সিডি চিত্রগুলি রেখেছি I এমনকি আমি ভিএম ভার্চুয়াল মেশিনকে (ভিএমডিকে সহ) উত্স নিয়ন্ত্রণে রাখার জন্য পরিচিত। চরম মনে হচ্ছে? 2 বছর পরে আমার বেকন সংরক্ষণ করা।
দ্রুত_ এখন

3
100% সম্মত। চিত্রগুলি যদি সফ্টওয়্যারটির অংশ হয় তবে তাদের পুনর্বিবেচনা নিয়ন্ত্রিত করা দরকার।
ডিন হার্ডিং

14
আমি একমত না হওয়ার কারণ হ'ল যদি এটি আপনার রেপোটিকে এমন পর্যায়ে ক্লোন করে তোলে যেখানে বিকাশকারীদের আসলেই ভাবতে হত "আমি কি আসলেই এটির ক্লোন করতে সময় নিতে চাই, বা আমি এই অন্যান্য শাখায় এক্স করতে পারি"? যদি এটি ঘটে থাকে তা নিশ্চিত হয়ে নিন যে জিনিসগুলি খুব তাড়াতাড়ি পুনরায় সংগঠিত হচ্ছে
ব্রুক

5
এটি মোতায়েনের জন্য প্রয়োজন সম্পর্কে পয়েন্টটির জন্য +1। যদি আমি আপনার রেপো ক্লোন করি, কারণ আমি একটি নতুন দলের সদস্য বা অন্য কিছু, তবে এটি বাক্সের বাইরে কাজ করা উচিত । এর মধ্যে একটি মেকফিল সমতুল চতুর থাকা অন্তর্ভুক্ত নয় যদি প্রয়োজন হয় তবে প্রয়োজনীয় তৃতীয় পক্ষের লাইব্রেরিগুলি পেতে যথেষ্ট।
স্পেনসার রথবুন

66

কেন না? :)

বাইনারি সংরক্ষণ করা খারাপ অনুশীলন হিসাবে বিবেচিত হয়, হ্যাঁ, তবে আমি চিত্রগুলি নিয়ে কখনই খুব বেশি চিন্তিত হইনি।

সবচেয়ে খারাপ ক্ষেত্রে, আপনার যদি টন থাকে তবে সেগুলি অন্য কোথাও সংরক্ষণ করুন বা বাইনারি সহায়তার জন্য বহিরাগত বা কোনও এক্সটেনশন ব্যবহার করুন। এবং যদি চিত্রগুলি প্রায়শই পরিবর্তন হয় না, তবে সমস্যা কোথায়? আপনি একটি বড় ফ্যাট ডেল্টা পাবেন না। এবং যদি তারা সময়ের সাথে সাথে মুছে ফেলা হয় তবে এটি কেবলমাত্র আপনার সার্ভার যা ইতিহাস সংরক্ষণ করে কিছুটা ভোগ করে, কিন্তু ক্লায়েন্টরা কোনও জিনিস দেখতে পাবেন না।

আমার মতে, আপনার এটি নিয়ে চিন্তা করা উচিত নয় - মঞ্জুর করে আপনি এর মধ্যে জিবি না সঞ্চয় করেন।

আপনি যা করতে পারেন তা কেবল "উত্স" চিত্রগুলি সংরক্ষণ করুন: এসভিজি, ল্যাটেক্স ম্যাক্রোস ইত্যাদি ... এবং আপনার বিল্ড সিস্টেমের মাধ্যমে তৈরি চূড়ান্ত চিত্রগুলি রয়েছে। এটি সম্ভবত আরও ভাল, আপনি যদি পারেন। যদি না হয় তবে বিরক্ত করবেন না।

(যা যা বলা হচ্ছে, সবগুলিই টেক্সট ফাইলগুলির জন্য জ্বলজ্বল করে, তবে ছবিগুলির জন্য সেরা ভিসিএস নয়। আপনি যদি পারেন তবে আমাদের আরও প্রসঙ্গ এবং মেট্রিক দিন)


অতিরিক্ত তথ্যের জন্য আপনি এই প্রশ্নোত্তর হিসাবে দেখতে চাইতে পারেন:


4
উত্স সংরক্ষণের জন্য +1, তবে তারা যদি পুরো বিল্ড ছাড়াই বিকাশের পরীক্ষা করতে পারে তবে তা এটিকে গোলমেলে ফেলতে পারে। এর অর্থ
হ'ল

@ দ্য এলকিউ: আমার ধারণা, তবে তারপরে সম্ভবত আপনার ক্যাসকেডিং বিল্ডগুলি থাকা উচিত, যেখানে আপনার ডাউনস্ট্রিম (পরীক্ষা) বিল্ডগুলি কেবলমাত্র মূল প্রবাহে (প্রকৃত বিল্ড) উপর নির্ভর করতে পারে। এবং তারপরে এগুলি স্থানীয়ভাবে পরীক্ষকগণ দ্বারা পুনরায় ব্যবহারের জন্য সর্বজনীন ফোল্ডারে রফতানি করুন। এটি কিছুটা অবকাঠামো স্পষ্টতই বোঝায়, তবে এটি আমার তুলনামূলকভাবে বড় দলে কাজ করার উপায়।
হাইলেম



5
"কেন না?" - কারণ যদি আপনার রেপো 2 জিবি ছাড়িয়ে যায়, বিটবকেট (এবং আমি কেবল এটি গিথুব দিয়ে চেষ্টা করেছি) আপনার রেপো প্রত্যাখ্যান করবে। তাই আপনি যদি টন ছবি দিয়ে সজ্জিত করেন তবে আপনার নিজস্ব রেপো হোস্ট করার জন্য প্রস্তুত থাকুন।
জেজ

48

এই প্রশ্নটি বেশ পুরানো তবে এটি একটি সাধারণ প্রশ্ন যা গিতের সাথে ডিল করার সময় উঠে আসে এবং শেষ উত্তর থেকেই গিট রেপোতে বড় বড় ফাইলগুলি সংরক্ষণ করার আধুনিক সমাধানগুলিতে কিছু অগ্রগতি রয়েছে।

গীতে বড় ফাইলগুলি সংরক্ষণের জন্য নিম্নলিখিত প্রকল্পগুলি রয়েছে:

টিএলডিআর: আপনি যদি পারেন তবে গিটে চিত্র বা অন্যান্য বাইনারি ফাইলগুলি সঞ্চয় করতে গিট-এলএফএস ব্যবহার করুন ।


9
দীর্ঘদিনের মধ্যে প্রথমবারের মতো, আমি খুব খুশী যে আমি নিম্ন-ভোট দেওয়া উত্তরগুলি পড়তে স্ক্রোল করেছিলাম। গিট এলএফএস হুবহু আমি যা চাই তা হ'ল, এবং অ্যাটলাসিয়ান এমনকি বিটবকেট সার্ভারে এর জন্য সমর্থন যোগ করেছেন ! আমি যদি এটি এক মিলিয়ন বার upvote করতে পারে, আমি চাই।
jonnybot

7
@ জনিবোট, ধন্যবাদ আমি দেরিতে উত্তর দিয়েছিলাম তাই আমি অনেক দৃশ্যমানতা অর্জন করতে পারি নি তবে গিট-এলএফএস নিজে ব্যবহার করার পরে এটি মনে হয় এটি গিটে বাইনারি ফাইলগুলি সংরক্ষণ করার জন্য সেরা বর্তমান সমাধান।
জেমস ম্যাকমাহন

45

পুরো "উত্স নিয়ন্ত্রণে বাইনারিগুলি সঞ্চয় করবেন না" নির্দিষ্ট কারণের জন্য প্রস্তুত করা হয়েছে: আপনার যদি সংস্থান করে এমন উত্স কোড থাকে তবে প্রকৃত সংকলনটি সংরক্ষণ করবেন না, তবে কেবল উত্স কোড। চিত্র এবং ভিজ্যুয়াল সম্পদের কোনও "উত্স" নেই, তাই সংস্করণ নিয়ন্ত্রণে সেগুলি ট্র্যাক করা উচিত


4
কখনও কখনও, চাক্ষুষ সম্পদের "উত্সের মতো কিছু" থাকে এবং তারপরে চূড়ান্ত আউটপুট তৈরির প্রক্রিয়াটি স্বয়ংক্রিয়ভাবে চালিত করা এবং কেবল উত্সটি নিয়ন্ত্রণ সংস্করণে সঞ্চয় করা ভাল ধারণা। উদাহরণস্বরূপ: এসভিজি ফাইলগুলি থেকে তৈরি রাস্টার গ্রাফিক সংস্করণ, একটি স্প্রিট শীট থেকে কাটা ওয়েবসাইট সম্পদ।
ট্যানিয়াস

সঠিক, এটি সম্পূর্ণ ন্যায্য যুক্তি।
জেসন টি ফেদারিংহাম

21

আমি বিশ্বাস করি গিটের সাথে প্রস্তাবিত উপায়টি হল একটি উপ-মডিউল (গিট 1.5.3.3 এ প্রবর্তিত) ব্যবহার করা যা মূলত একটি পৃথক সংগ্রহস্থল যা মূলটির সাথে সম্পর্কিত। আপনি আপনার চিত্রগুলি (এবং অন্যান্য বাইনারি সম্পদগুলি) উপ-মডিউলে সংরক্ষণ করুন। এরপরে প্রয়োজনীয় সংগ্রহের উপর নির্ভর করে মূল সংগ্রহস্থল বা বামে দিয়ে এটি পরীক্ষা করা যেতে পারে।

Http://book.git-scm.com/5_submodules.html থেকে

"গিটের সাবমডিউল সমর্থন কোনও উপ-ডিরেক্টরি হিসাবে একটি বহিরাগত প্রকল্পের একটি চেকআউট রাখার জন্য একটি সংগ্রহস্থলকে মঞ্জুরি দেয় ules সুপারপ্রজেক্ট ") একই সংশোধনীতে সহজেই সমস্ত সাবমোডিয়ুল ক্লোন করতে পারে the

এছাড়াও, চিত্রগুলি প্রায়শই পরিবর্তন হয় না তবে আকার কোনও গুরুত্বপূর্ণ বিষয় হওয়া উচিত নয়। আপনি আকার ছাঁটাই / কমাতে কমান্ডগুলি চালাতে পারেন, যেমন:

git gc
git gc-aggressive
git prune

7

হ্যাঁ

বলুন আপনি সফ্টওয়্যার সংস্করণ 1.0 প্রকাশ করেছেন। সংস্করণ ২.০ এর জন্য আপনি ছায়ার সাথে থাকা সমস্ত ছবি পুনরায় করার সিদ্ধান্ত নিয়েছেন। সুতরাং আপনি এটি করেন, এবং 2.0 প্রকাশ করুন। তারপরে কিছু গ্রাহক যারা 1.0 ব্যবহার করছেন এবং 2.0 তে আপগ্রেড করতে পারবেন না তারা সিদ্ধান্ত নেন যে তারা অন্য ভাষায় প্রোগ্রামটি চান। তারা আপনাকে এটি করার জন্য $ 1G দেয়, তাই আপনি নিশ্চিতই বলে। তবে ভিন্ন সংস্কৃতিতে আপনার কয়েকটি ছবি অর্থবোধ করে না, তাই আপনাকে সেগুলি পরিবর্তন করতে হবে ...

যদি আপনি আপনার চিত্রগুলি উত্স নিয়ন্ত্রণে রাখেন তবে এটি সহজ, 1.0 এর উপর ভিত্তি করে আপনি চিত্রগুলিতে পরিবর্তন করেন (অন্যান্য জিনিসের মধ্যে), বিল্ড, রিলিজ। আপনার যদি সোর্স কন্ট্রোল এ না থাকে তবে আপনার অনেক বেশি কঠিন সময় হবে, যেহেতু আপনাকে পুরানো চিত্রগুলি খুঁজে পেতে হবে, সেগুলি পরিবর্তন করতে হবে এবং তারপরে তৈরি করতে হবে।


7

যদি এটি প্রকল্পের অংশ হয় তবে এটি ভিসিএসে থাকতে হবে । কীভাবে এটি সর্বোত্তম অর্জন করা যায় তা ভিসিএসের উপর নির্ভর করে, বা আপনি কীভাবে কোনও প্রকল্প সংগঠিত করেন। হতে পারে ডিজাইনারদের জন্য কোনও রেপো এবং কেবল কোডারের রেপোতে বা কেবল 'চিত্রের উত্স' (আমার একবারে একটি .svg ফাইল, এবং মেক / ইনস্কেপ ক্লাইমের মাধ্যমে তৈরি হওয়া চিত্রগুলির সাথে একটি প্রকল্প হয়েছিল)।

তবে, যদি কোনও ভিসিএস এটি পরিচালনা করতে না পারে বা অকেজো হয়ে যায় তবে আমি বলব যে এটি আপনার কাজের উপযুক্ত সরঞ্জাম নয়।

এখনও অবধি, গিতে ওয়েব প্রকল্পের জন্য 'স্বাভাবিক' পরিমাণের গ্রাফিক্স (মকআপস, ধারণাগুলি এবং পৃষ্ঠা গ্রাফিক্স) লাগাতে আমার কোনও সমস্যা হয়নি।


5

আপনার যদি আপনার ছবিগুলি এসসিএম-এ সঞ্চয় করা উচিত: হ্যাঁ। কোন সন্দেহ ছাড়া.

আপনার ছবিগুলি গিটে সংরক্ষণ করা উচিত: এটি আরও জটিল।

পাঠ্য ফাইলগুলির সাথে গিটটি খুব ভাল, তবে এর প্রকৃতির দ্বারা বাইনারিগুলির সাথে খুব বেশি গরম নেই। আপনি ক্লোন বা ধাক্কা দেওয়ার সময় স্থানান্তরিত ডেটার আকারের সাথে আপনার সমস্যা থাকবে, আপনার .git ডিরেক্টরিগুলি বৃদ্ধি পাবে এবং আপনি মার্জ হওয়ার সাথে সাথে সঠিক মেসে উঠতে পারেন (যেমন আপনি কীভাবে 2 টি চিত্র মার্জ করবেন!)

একটি উত্তর হ'ল সাবমডিউলগুলি ব্যবহার করা, কারণ এর অর্থ আপনার প্রকল্প এবং চিত্রগুলির মধ্যে যোগসূত্রটি দুর্বল হয়ে যাবে - সুতরাং আপনাকে চিত্রগুলি এমনভাবে পরিচালনা করতে হবে না যেন সেগুলি আপনার উত্সের অংশ, তবুও সেগুলি নিয়ন্ত্রিত রাখে, না থাকে তাদের শাখা নিয়ে উদ্বেগ - এই অনুমান করা যে সাবপ্রজেক্টটি কেবলমাত্র ডেটাগুলির একটি 'সমতল' ভাণ্ডার যা সাধারণ বিকাশের প্রক্রিয়া চলাকালীন একই মন্থনে যায় না।

অন্য উত্তরটি হ'ল এগুলিকে একটি ভিন্ন প্রকল্পে স্থাপন করা, এটি কখনই শাখা না করা এবং নিশ্চিত হওয়া উচিত যে এই প্রকল্পে প্রতিবেদন করা প্রত্যেকে তত্ক্ষণাত উজানে প্রবাহিত করবে - 2 জনকে কখনও ফাইলের একই সংস্করণটি পরিবর্তন করতে দেবে না - আপনি এটি সবচেয়ে জটিল খুঁজে পাবেন গিট হিসাবে দিকটি এমন একটি বিতরণযোগ্য ওয়ার্কফ্লোয়ের জন্য ডিজাইন করা হয়নি। এই নিয়মটি বর্ধন করার জন্য আপনাকে পুরানো কালের যোগাযোগ পদ্ধতি ব্যবহার করতে হবে।

তৃতীয় উত্তর হ'ল এগুলিকে পুরোপুরি আলাদা একটি এসসিএম এ রাখলে এটি চিত্রের সাথে কাজ করার জন্য আরও ভাল।


0

@ হাইলিমের উত্তরে যুক্ত করে মনে রাখবেন যে আকারটি এতে একটি বড় ফ্যাক্টর খেলে। ভিসিএসের উপর নির্ভর করে এটি টন ইমেজের সাথে ভাল কাজ করতে পারে না। ক্লোন বা বড় ধাক্কা যখন সারা রাত ধরে নেওয়া শুরু করে তখন সমস্ত চিত্র ইতিমধ্যে আপনার ভান্ডারে রয়েছে বলে এর ফলে অনেক দেরি হয়ে গেছে।

বড় ছবি এবং ভবিষ্যতের বৃদ্ধির পরিকল্পনা করুন। আপনি ", হয়তো রেপো একটু হয় উহু বিষ্ঠা এই প্রকল্পের মধ্যে দুই বছর পেতে এবং একটি আছে চাই না খুব বড়।"


1
আপনার উত্তরটি কিছুটা অপ্রাসঙ্গিক, কারণ প্রশ্নটি গিটের জন্য নির্দিষ্ট। আপনি কি জানবেন যে গিট সংগ্রহস্থলগুলির জন্য আকার কোনও বৃহত (বা কোনও) ফ্যাক্টর খেলে কিনা?
ইয়ানিস

@ ইউনিস মাস্টের প্রথম বাক্যটি মিস করা উচিত ... আফাইক, বৃহত্তর সংগ্রহস্থলগুলির সাথে গিট আরও ভাল তবে আকারের বিষয়টি এখনও প্রাসঙ্গিক কারণ
গ্যারান্টুয়ান

জিআইটি-র সাহায্যে খুব সহজেই সংগ্রহস্থলগুলি পুনরায় সাজানো এবং আংশিক ক্লোন ইত্যাদি তৈরি করা সহজ হয়, যদি এটি সমস্যা হয়ে থাকে। দশকের আগে থেকে আজকের সংস্করণ নিয়ন্ত্রণ সরঞ্জামগুলির historicalতিহাসিক গুড়কে বিভ্রান্ত করবেন না।
mattnz

0

আমি স্পষ্টভাবে একমত যে প্রযুক্তিগত এবং অর্থনৈতিকভাবে সেগুলি সংরক্ষণ করা সম্ভব। প্রশ্নটি আমি যেমন করব "এই চিত্রগুলি কি শিপিং পণ্যের অংশ বা কোনও শিপিং পণ্যের সামগ্রীর অংশ?" আপনি জিআইটি (বা অন্য কোনও ভিসিএস) তে সামগ্রী সংরক্ষণ করতে পারবেন না তবে এটি পৃথক ভিসিএসের জন্য পৃথক সমস্যা।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.