वर्कफ़्लो: बिना लॉक के Git में द्विआधारी दस्तावेज़ स्वरूपों का उपयोग करना (तोड़फोड़ से आगे बढ़ना)


16

हम विभिन्न ग्राहकों के लिए कई परियोजनाओं के साथ एक सॉफ्टवेयर कंसल्टेंसी हैं। हम परंपरागत रूप से तोड़फोड़ का उपयोग करते हैं, लेकिन वर्तमान में गिट में जाने पर विचार कर रहे हैं।

हमारे द्वारा उत्पादित दस्तावेजों का एक महत्वपूर्ण हिस्सा हमारे ग्राहकों (आवश्यकताओं, वैश्विक डिजाइन, परीक्षण चश्मा, आदि) के साथ साझा किया जाता है, और हम इनका उत्पादन करने के लिए एमएस ऑफिस का उपयोग करते हैं। तोड़फोड़ में, हम यह सुनिश्चित करने के लिए इसकी "लॉक" सुविधा का उपयोग कर सकते हैं कि कोई भी एक ही समय में एक ही दस्तावेज़ को संपादित नहीं कर रहा था। Git में, आप ऐसा नहीं कर सकते क्योंकि इसकी वितरित प्रकृति से, git में ताले नहीं हैं।

ताले वास्तव में एक संचार तंत्र से बहुत कम हैं, लेकिन वे एक बहुत प्रभावी हैं।

वर्तमान में, हमारे कोड और ग्राहक-सामना वाले दस्तावेज़ आम तौर पर एक अलग svn रिपॉजिटरी के विभिन्न सबफ़ोल्डर्स में होते हैं। जब आप आगे बढ़ते हैं, तो आप हमें क्या करने की सलाह देंगे? मुझे विकल्पों का एक सेट दिखाई देता है:

  1. हम 1-ऑन -1 को git करने के लिए svn रिपॉजिटरी को स्थानांतरित करते हैं। Office फ़ाइलों पर ताले का उपयोग करने के बजाय, हम वही करते हैं जो गिट लोग सुझाते हैं और किसी तरह इसे ठीक करने के लिए हमारे वर्कफ़्लो को बदलने का प्रयास करते हैं। यह किसी भी दस्तावेज़ को संपादित करने वाली शाखा में काम कर सकता है, और उस समीक्षा में विलय कर सकता है। यह दृष्टिकोण उदाहरण के लिए एक्सेल शीट पर टूटता है जिसमें परियोजना प्रबंधन जानकारी होती है; वे टीम के सदस्यों द्वारा आसानी से संपादित किए जाते हैं (और हम इसे प्रोत्साहित करते हैं), लेकिन किसी भी औपचारिक समीक्षा प्रक्रिया के अधीन नहीं

  2. हम डॉक्स और प्रोजेक्ट प्रबंधन के लिए कोड और svn के लिए git का उपयोग करते हैं। इसका नुकसान यह है कि कुछ और डिज़ाइन-ईश दस्तावेज़ों को कोड के "पास" नहीं किया जाएगा, जिससे यह संभावना बढ़ जाती है कि लोग उन्हें अपडेट करना भूल जाते हैं। इसके अतिरिक्त, सभी को दो सेट टूल का उपयोग और समझना होगा। कहा, हो सकता है कि यह गैर-ग्राहक-सामना करने वाले डिज़ाइन डॉक्स के लिए पाठ-आधारित डॉक्टर उपकरण (लेटेक्स, मार्कडाउन, HTML, जो भी हो) में जाने का एक शानदार अवसर है।

  3. 1 की तरह, लेकिन हम एक git lockकमांड को हैक करते हैं जो कि svn लॉक हमारे लिए करता है (उचित माध्यम से रीड-ओनली फ्लैग को टॉगल करें और कुछ माध्यमों से सर्वर के साथ सिंक करें)।

मैं इस तर्क को नहीं खरीदता कि डीवीसीएस में ताले काम नहीं करते क्योंकि सिस्टम पूरी तरह से ऑफ़लाइन होने पर भी काम करना चाहिए। स्वॉन लॉक को भी ओवरराइड किया जा सकता है; वे एक संचार तंत्र हैं। कुछ प्रकार के नेटवर्क कनेक्शन के बिना, आपको अपने कंप्यूटर को बहुत अधिक संवाद करने के लिए नहीं मिलेगा।

हम एकमात्र दुकान नहीं हो सकते हैं जो svn lockहमारे वर्कफ़्लो में फिट होने के साथ बहुत खुश हैं , है ना?

किसी भी विचार या सुझाव?

मैंने पाया कि /programming/119444/locking-binary-files-use-git-version-control-system लेकिन चर्चा बल्कि तकनीकी है; मैं एक ही समय में एक ही बाइनरी फ़ाइल को संपादित करने वाले दो टीम के सदस्यों की व्यावहारिक समस्या को हल करने या बचने के तरीकों की तलाश कर रहा हूं।


क्या आप स्पष्ट कर सकते हैं कि आप ग्राहकों के साथ अपने दस्तावेज़ों को "साझा" कैसे करते हैं? मुझे उम्मीद है कि उनके पास केवल पढ़ने के लिए पहुंच है और परिवर्तन आपकी टीम द्वारा प्रबंधित किए जाते हैं, क्योंकि उनसे परिवर्तन के अनुरोध। क्या वो सही है?
विन्गंड्रोइड

2
आप बाइनरी दस्तावेज़ों को संभालने के लिए VCS के बजाय एसेट मैनेजमेंट टूल (लॉकिंग फीचर के साथ) का उपयोग करना चाह सकते हैं। मैंने ऐसी जगह पर काम किया जिसमें SVN में 2 GB och इमेज चेक की गईं, जिसने सब कुछ सुपर स्लो कर दिया। हम सभी को बैक-अप चीजों के तहत एक फ़ोल्डर में ले जाने के बाद तेजी से और संभालना आसान हो गया।
Spoike

1
@Baqueta ईमेल द्वारा या कागज पर। मुद्दा यह है कि "डॉक्स के लिए केवल पाठ का उपयोग करें!" यहाँ एक उचित दृष्टिकोण नहीं है, क्योंकि इसे आधे-सभ्य दिखने में शामिल प्रयास एमएस वर्ड जैसे उपकरणों की तुलना में बहुत अधिक है।
स्क्रेबेल

@ साइकिक, मुझे एक मान्य उत्तर की तरह लगता है :-) वैसे भी, कोई सिफारिशें?
स्क्रेबेल

@skrebbel एक शब्द, LaTeX।
कियारास

जवाबों:


5

मैं आपको दो कारणों से एमएस ऑफिस के दस्तावेजों के लिए एसवीएन के साथ बने रहने की सलाह दूंगा:

  1. यह पहले से ही है और यह (मेरी राय में) ऑफिस के दस्तावेजों को रखने के लिए बेहतर है ( यहां देखें )। ऐसा करने के लिए बहुत अधिक तृतीय पक्ष उपकरण हैं।
  2. लॉक, हालांकि गिट में प्राप्त किया जा सकता है, "चीजों को करने का तरीका नहीं है"। यदि आपको इन सुविधाओं की आवश्यकता है, तो उस टूल के साथ रहें जो आपको सबसे अच्छा समाधान देता है।

एक कहावत है कि मुझे यह पसंद है कि कुछ इस तरह से कहे: "जब आप एक हैमर पकड़े हुए हैं, तो सब कुछ एक नाखून की तरह दिखता है"। सिर्फ इसलिए कि आप अपना कोड रखने के लिए Git में जा रहे हैं, इसका मतलब यह नहीं है कि आपको अपने दस्तावेज़ों को रखने के लिए इसका उपयोग करना चाहिए।


क्या होगा यदि कोड और दस्तावेज एक ही एसवीएन रिपॉजिटरी में हों?
जिमी टी।

2

Office फ़ाइलों पर काम करने के लिए कोड संस्करण नियंत्रण सबसे अच्छा उपकरण नहीं है, क्योंकि वे द्विआधारी हैं और ये उपकरण फ़ाइल-स्तरीय संशोधन पर काम करते हैं।

एक सहयोग उपकरण का उपयोग करें, जैसे मीडियाविकि (फ्री) या एटलसियन कंफ्लुएंस (भुगतान किया हुआ), जिससे आप आसानी से वर्ड डॉक्यूमेंट निकाल सकते हैं। या Office फ़ाइलों को बनाने के लिए LaTex का उपयोग करें।

मुझे विस्तार दें ...

यदि आपको सहयोग करने की आवश्यकता है, तो आपको एक मॉडल को अपनाना होगा जो संशोधनों को हाइलाइट करता है (जैसे एक शब्द, रीफ़्रेश किया गया, या बस एक फ़ॉन्ट बदला) एक इकाई, जैसे एक फ़ाइल।

एसवीएन और गिट, भले ही कोड के लिए सोचा गया हो, निम्न स्तर के उपकरण हैं जो पाठ सामग्री द्वारा अपनी फ़ाइलों की तुलना करते हैं। लेकिन समस्या यह है कि वे केवल पाठ फ़ाइलों पर काम कर सकते हैं, क्योंकि वे उच्च-स्तरीय संशोधन मॉडल को निकालने के लिए फ़ाइल की प्रकृति / सामग्री के बारे में परवाह नहीं करते हैं।

एक स्पष्ट उदाहरण एक छवि फ़ाइल है । हालांकि TortoiseMerge एक उपकरण है जो SVN उपयोगकर्ताओं को उनके वास्तविक संशोधनों के लिए छवियों की तुलना करने में मदद करता है , फाइलों पर VCSसामग्री पैच द्वारा सामान्य एस रन । मुझे समझाने दो। TortoiseMerge जैसा टूल आपको बता सकता है कि एक छवि फ़ाइल का एक नया संस्करण केवल कुछ पिक्सेल द्वारा बदल दिया जाता है, या यदि यह दो फ़ाइलों के अधिक जटिल एचएसवी विश्लेषण को लागू करता है, तो ल्यूमिनेंस। आप वॉटरमार्क जोड़ सकते हैं या रंग स्तर बदल सकते हैं, एक उपकरण जो छवि फ़ाइलों की तुलना करता है, यदि यह अच्छी तुलना एल्गोरिथ्म लागू करता है, तो आप अंतरों को उजागर करेंगे । लेकिन क्रम में अपने ग्राहक में नई फ़ाइल की जाँच करने में करना चाहिएएक डेल्टा का उत्पादन। एक डेल्टा लाइनों का एक सेट है जिसे हटा दिया जाता है और लाइनें जो फ़ाइल में जोड़ी जाती हैं। यदि उनके पास या उनके पेलोड में और उसके समान नहीं है\r\n , तो बाइनरी फ़ाइलों में कोई लाइन ब्रेक नहीं होती है , और यदि आप एक एकल वर्ण को बदलते हैं, तो एक डेल्टा में।

तो यहाँ समस्या है। बाइनरी फाइलें संस्करण नियंत्रण के लिए अच्छी नहीं हैं क्योंकि आप प्रत्येक संशोधन के लिए पूरी फाइल को लगभग बदल सकते हैं। जब आप MS Office और अपने सहयोगी को OpenOffice के साथ संपादन करते हुए Office फ़ाइलें लिखते हैं, तो विचार करें। यदि वे OpenXML फ़ाइलों के संपीड़न एल्गोरिदम का थोड़ा अलग संस्करण भी लागू करते हैं, तो आप दस्तावेज़ में एक एकल अल्पविराम बदलने पर भी पूरी तरह से अलग फ़ाइलों में समाप्त हो जाएंगे ।

सॉफ्टवेयर्स डॉक्युमेंट्स को टेक्स्ट-बेस्ड फॉर्मेट में आंतरिक रूप से प्रस्तुत करते हैं, क्योंकि टेक्स्ट वही है जो आपकी कंपनी के लिए वास्तव में सार्थक है, और मतभेदों की गणना कर सकता है या विरोधों को संभाल सकता है। यदि आप पसंद करते हैं, तो LaTex, या Markdown, उन्नत मार्कअप के साथ एक डॉक्यूमेंट को एक स्टोरेज फ़ाइल के रूप में संग्रहीत करने का एक तरीका है , इसलिए क्लासिक TXT फ़ाइल की तरह नहीं जिसमें कोई फ़ॉन्ट / स्वरूपण नियंत्रण नहीं है।

लेकिन जाहिर है कि आपके ग्राहक मार्कडाउन फाइलें खोलना पसंद नहीं करेंगे, क्या वे करेंगे? ठीक है, आप बस कर सकते हैं, और मैं वास्तव में बस का मतलब है, किसी भी सॉफ्टवेयर का उपयोग कर रहा हूँ मैं वर्तमान में पीडीएफ, वर्ड या जो भी करने के लिए एक स्रोत दस्तावेज़ परिवर्तित करने के लिए Google के लिए बहुत आलसी हूँ ।

सारांश

यदि आप अपने स्रोत नियंत्रण में पाठ फ़ाइलों की जाँच करना शुरू करते हैं, तो आपके पास फ़ाइल इतिहास पर अधिक नियंत्रण है और आसानी से टकरावों का प्रबंधन कर सकते हैं, खासकर वीसीएस ताले का उपयोग किए बिना।

किसी दस्तावेज़ को आधिकारिक रूप से साझा करने से पहले आपको स्रोत फ़ाइल दस्तावेज़ को किसी Office फ़ाइल में निर्यात करने के लिए एक रूटीन की आवश्यकता होती है

दो चरणों को अलग करना लोगों को सीखने की अवस्था की कीमत पर खुश करता है।


लिनक्स और मैक टेक्स्ट फाइलों में आपकी परिभाषा के अनुसार या तो लाइनें नहीं होतीं हैं> डेल्टा को बाइनरी फ़ाइलों के लिए आसानी से बनाया जा सकता है। आप एक अलग एल्गोरिथ्म पर निर्णय लेते हैं। उदाहरण के लिए SVN बाइनरी फ़ाइलों के लिए अच्छा, छोटा डेल्टा बनाता है (कम से कम बड़ी। Dll फ़ाइलों के साथ जो मुझे सबसे अधिक अनुभव है)
gbjbaanb

हां, गैर-विंडोज में अलग-अलग लाइन टर्मिनेटर हैं। वैसे भी यदि आप एक छोटा डेल्टा बनाने का प्रबंधन करते हैं (मुझे उत्तर को थोड़ा सा फिर से लिखना होगा) क्या यह अंतर मानव-पठनीय बनाता है? बिलकूल नही। आप यह नहीं बताएंगे कि DLL के बीच किन वर्गों को संशोधित किया गया है। और फिर समस्या दो संकलक कि है हो सकता है (मैंने कहा हो सकता है ) कक्षाओं तरह वे तरह का क्रम बदल कर पूरी तरह से अलग फ़ाइलों का उत्पादन। यह उत्तर का बिंदु था
usr-local-'Mar

-1

आप उन दस्तावेजों के लिए git का उपयोग लॉकिंग को जोड़े बिना कर सकते हैं। एक मास्टर चुनें जो मास्टर ब्रांच को ब्लॉक करता है यदि मास्टर पर नहीं है। (चुनने के लिए कई वर्कफ़्लोज़ हैं।) यह लोगों को द्विआधारी दस्तावेज़ फ़ाइलों में एक-दूसरे के संशोधनों को अधिलेखित करने से रोक देगा। मान लें कि दो लोग एक ही बाइनरी दस्तावेज़ को संशोधित करते हैं। पहला जो इसे मास्टर को धकेलता है, वह अपने परिवर्तनों को प्राप्त करता है। दूसरा व्यक्ति अवरुद्ध हो जाएगा क्योंकि उनकी प्रतिलिपि मास्टर शाखा के पीछे है। उन्हें पहले सिंक करना होगा। तो दूसरा व्यक्ति सिंक करता है। यह बाइनरी दस्तावेज़ के लिए मर्ज संघर्ष दिखाएगा। वह व्यक्ति अपने संस्करण को कहीं बचाता है और संस्करण को मास्टर से ले कर संघर्ष को हल करता है (जो कि पहले व्यक्ति द्वारा धक्का दिया गया था)। इस बिंदु पर दूसरे व्यक्ति की फाइलें मास्टर शाखा के साथ अद्यतित हैं। वे अपने परिवर्तनों को नवीनतम बाइनरी दस्तावेज़ (हाथ से) में मर्ज करते हैं, जिसमें बाद में पहले व्यक्ति और दूसरे व्यक्ति के परिवर्तन दोनों शामिल होंगे। फिर नए संस्करण को मास्टर में धकेल दिया जाता है और नई मास्टर शाखा बन जाती है। विलय एक दर्द है, लेकिन यह केवल तब होता है जब कोई संघर्ष होता है। इसके अलावा, परिवर्तन खो या अधिलेखित नहीं मिलता है। संघर्ष का पता लगाया जाता है और उपयोगकर्ता उन्हें सफाई से हल करने में सक्षम होते हैं।


4
वास्तव में यह मर्जिंग दर्द है जिसे रोकने के लिए तालों को माना जाता है।
oefe

वास्तव में मर्ज टूल हैं जो वर्ड दस्तावेजों को मर्ज कर सकते हैं। मेरे पास हालांकि उनके साथ कोई अनुभव नहीं है, इसलिए वे कितने अच्छे हैं, इसका मुझे कोई अंदाजा नहीं है?
पीट

आपके उत्तर के लिए धन्यवाद। मैं देखता हूं कि यह काम करने का तरीका है। @Pete, वर्ड अपने आप में एक बहुत ही सभ्य डिफ ​​कर सकता है, मर्ज के बारे में निश्चित नहीं है। लेकिन फिर भी, यह एक दर्द है जो ताले से आसान है। हम शायद ही कभी कार्यालय दस्तावेजों को एक साथ संपादित करते हैं; हमारे अधिकांश कार्य (विस्तृत डॉक्स सहित) कोड में हैं। इस सवाल के बारे में ऐसे मामलों में जहां 2 लोगों के 2% है कर संपादित एक ही समय में एक ही दस्तावेज़। यह देखते हुए कि यह 2% है, 30% नहीं है, एक मर्ज समाधान उप-विषयक लगता है।
स्क्रेबेल

-2

अपने पहले 2 समाधानों को एक साथ रखें और आपको तीसरे की आवश्यकता नहीं है।

यदि आप अपने स्प्रैडशीट को CSV के रूप में डिस्क पर सहेजते हैं, तो एक्सेल अभी भी उन्हें संपादित करेगा और फिर git को आपके लिए मर्ज करने में खुशी होगी।

इसी तरह, यदि आप HTML या (भगवान हमारी मदद करते हैं) RTF में अपनी फ़ाइलों को खोल सकते हैं, संपादित कर सकते हैं और सहेज सकते हैं। वर्ड ऑफ कोर्स उपयोगी पाठ की तुलना में अधिक ब्लोट को जोड़ देगा, लेकिन यह अभी भी सिर्फ पाठ है जो आपके लिए विलय करने के लिए खुश है।

दी, ये समाधान मानते हैं कि आप उपयोग नहीं करते हैं या एमएस-विशिष्ट सुविधाओं से दूर जा सकते हैं जो वास्तव में केवल एक्सेल की तरफ एक मुद्दा है।

जब तक निश्चित रूप से आपको अपने दस्तावेज़ को पढ़ने में सक्षम होने के लिए एक सिस्टम पर स्थापित होने के लिए वर्ड की भी आवश्यकता होती है, जो अपने आप में एक भयानक संभावना है ...


1
वास्तव में? क्या आप मर्ज संघर्ष से बचने में सक्षम होने के लिए पाषाण युग में एक वापसी का सुझाव दे रहे हैं?
पेट्टर नॉर्डलैंडर

मुझे यकीन नहीं है कि मुझे समझ में आ रहा है कि आप क्या महसूस कर रहे हैं पत्थर की उम्र पाठ प्रारूप बनाम बाइनरी प्रारूप में संग्रहीत करने के बारे में है ...
स्टीवन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.