एक्सेस स्रोत कोड नियंत्रण के लिए OASIS-SVN और git का उपयोग करना

नोट: मैं इस विषय के बारे में आगामी एक्सेस और SQL सर्वर मासिक वेबिनार में 9 जुलाई को शाम 6:30 बजे सीडीटी में गहराई से बात करूंगा। रजिस्टर करें ताकि आप प्रक्रिया को लाइव देख सकें और प्रश्न पूछ सकें!

जैसा कि हम कई अनुप्रयोगों और कभी-कभी एक टीम में काम करते हैं, परिवर्तनों के प्रबंधन के लिए स्रोत कोड नियंत्रण बहुत महत्वपूर्ण है। हम अपनी परियोजनाओं के लिए git का उपयोग करना पसंद करने लगे हैं। मूल रूप से, एक्सेस के साथ git का उपयोग करना एक चुनौती होगी, लेकिन OASIS-SVN नामक ऐड-इन के लिए धन्यवाद, हम परिवर्तनों को प्रबंधित करने के लिए एक्सेस प्रोजेक्ट्स के साथ git का प्रभावी ढंग से उपयोग कर सकते हैं।

स्रोत कोड नियंत्रण का उपयोग क्यों करें? क्या आप इसे केवल ज़िप नहीं कर सकते?

स्रोत कोड नियंत्रण के पीछे मुख्य लक्ष्य whodunit का आसानी से उत्तर देने में सक्षम होना है।

यह विशेष रूप से महत्वपूर्ण है जब आप एक बग रिपोर्ट के साथ काम कर रहे हैं और आपको याद दिलाया जाता है कि आपने पहले भी कुछ ऐसा ही देखा था और आपने सोचा था कि शायद आपने इसे ठीक कर दिया है लेकिन ग्राहक अभी भी इसकी रिपोर्ट कर रहा है। हालाँकि, जब बग छह महीने पहले "ठीक" किया गया था, तो यह एक बिल्कुल नया बग भी हो सकता है क्योंकि हम पहले से ही 6 महीने पहले किए गए सुधार के बारे में भूल गए हैं। मैं आपके बारे में नहीं जानता लेकिन ज़िप किए गए बैकअप के एक समूह के माध्यम से खुदाई करने की संभावना बहुत … खोजने योग्य नहीं लगती है।

अपने परिवर्तनों को स्रोत कोड नियंत्रण में रखने के लिए अनुशासन की आवश्यकता होती है, लेकिन इससे परिवर्तनों की समीक्षा और प्रबंधन करना बहुत आसान हो जाएगा। आप आसानी से इतिहास खोज सकते हैं और देख सकते हैं कि वास्तव में क्या परिवर्तन होता है।

एक और परिदृश्य यह पता लगा रहा है कि वास्तव में क्या बदला है। यदि आपने कई बदलाव किए हैं और नए संस्करण को आगे बढ़ाने से पहले आपको उनकी समीक्षा करने की आवश्यकता है, तो स्रोत कोड नियंत्रण आपकी मदद करता है। आपके पास अपने काम की जांच करने और यह सुनिश्चित करने का अवसर है कि आपने वह सब किया जो आपने करने के लिए निर्धारित किया था। और नहीं "मुझे लगता है कि मैंने पहले ही ऐसा कर लिया है।" केवल क्लाइंट द्वारा बताए जाने के लिए आप उस मामूली विवरण को भूल गए हैं जो क्लाइंट ने आपसे पिछले सप्ताह पूछा था। इसके अलावा, यह टीम को दूसरों के लिए कोड समीक्षा करने में सक्षम बनाता है; हम दूसरों के काम को देख सकते हैं और फीडबैक प्रदान कर सकते हैं और एक दूसरे की गुणवत्ता के उच्च स्तर को बनाए रखने में मदद कर सकते हैं।

गिट क्यों? एक्सेस विजुअल सोर्ससेफ के साथ काम करता है न?

एक्सेस 2013 से पहले के संस्करणों में, एक्सेस ने स्रोत कोड नियंत्रण को मूल रूप से नियंत्रित किया, लेकिन इसने एक मालिकाना Microsoft विनिर्देश, MSSCCI का उपयोग किया। इसे बदतर बनाने के लिए, विनिर्देश एक चेक-आउट/चेक-इन मॉडल मानता है जो डेवलपर्स को उन वस्तुओं पर एक विशेष लॉक देता है जो वे काम कर रहे हैं। इसके अलावा, एक्सेस एप्लिकेशन के भीतर टेबल मूल रूप से एक बड़ा ब्लॉब था जिसे पढ़ा नहीं जा सकता था, अकेले समीक्षा की गई।

व्यवहार में, ऐसा मॉडल छोटी टीम सेटिंग्स में भी उपयोग करने के लिए बहुत बोझिल है। एक मुख्य मुद्दा यह है कि एक परिवर्तन अनुरोध की पुष्टि शायद ही कभी केवल एक वस्तु के लिए की जाती है; डेवलपर्स को खुद को मुट्ठी भर वस्तुओं से अधिक स्पर्श करने की आवश्यकता हो सकती है और इस प्रकार, टकराव अपरिहार्य हो सकता है, खासकर कोर/साझा मॉड्यूल के लिए।

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

गिट सीखने के लिए एक उत्कृष्ट संसाधन यहां पाया जा सकता है; इसमें एक सैंडबॉक्स है जिससे आप साथ खेल सकते हैं। यदि आप मेरे जैसे हैं और भावपूर्ण बिट्स को काटना पसंद करते हैं और जानते हैं कि यह कैसे काम करता है, तो यह एक अच्छा संसाधन है।

अंत में, पहले से ही Visual SourceSafe का उपयोग करना बंद कर दें। यह छोटी गाड़ी है, आपका डेटा खोने का खतरा है और इसे _years_ के लिए समर्थित नहीं किया गया है, यहां तक ​​कि 2013 से एक्सेस द्वारा भी नहीं।

लेकिन अगर एक्सेस 2013+ अब स्रोत कोड नियंत्रण का समर्थन नहीं करता है, तो हम इसे अभी भी कैसे प्राप्त कर सकते हैं?!?

क्योंकि OASIS-SVN एक MSSCCI प्रदाता नहीं है, बल्कि एक सादा एक्सेस ऐड-इन है। अन्य समान एक्सेस ऐड-इन्स हैं (उदाहरण के लिए Ivercy उदाहरण के लिए) जो सीमा के आसपास काम करता है। सभी मामलों में, वे एडिन ठीक उसी गैर-दस्तावेजी विधियों का भारी उपयोग करते हैं जो एक्सेस स्रोत कोड नियंत्रण के लिए आंतरिक रूप से उपयोग किए जाते हैं; Application.SaveAsText और Application.LoadFromText . वे विधियां अभी भी एक्सेस के वर्तमान संस्करण में मौजूद हैं। एक तरफ, निरंतरता सुनिश्चित करने के लिए इसे दस्तावेज करने के लिए एक यूवी आइटम है। ओएसिस-एसवीएन वर्तमान एक्सेस संस्करण के साथ भी अच्छी तरह से काम करना जारी रखता है।

आप OASIS-SVN और git के बारे में क्यों बात करते रहते हैं? क्या मैं सिर्फ एक या दूसरे का उपयोग कर सकता हूं?

यह समझना महत्वपूर्ण है कि दोनों उपकरण पूरक हैं और आपको दोनों की आवश्यकता है। देखें, आपको OASIS-SVN की आवश्यकता क्यों है, यह आपके लिए अपनी कड़ी मेहनत को निकालना और उन्हें एक बाइनरी फ़ाइल के एक बड़े ब्लॉब के अंदर रखने के बजाय टेक्स्ट फ़ाइलों के एक समूह के रूप में प्रस्तुत करना आसान बनाना है। एसीसीडी * फ़ाइल। एसीसीडीबी फ़ाइल को स्रोत कोड नियंत्रित करने का कोई मतलब नहीं है क्योंकि इसमें परिवर्तन का उचित इतिहास नहीं होगा और यह काफी हद तक अपठनीय होगा। इस प्रकार, OASIS-SVN टेक्स्ट फ़ाइलों को बनाने के लिए उपकरण है जिनका उपयोग आपके एक्सेस एप्लिकेशन के पुनर्निर्माण के लिए किया जा सकता है, और यह वास्तव में उन फ़ाइलों को स्रोत-कोड करने के लिए git का काम है। git ACCDB फ़ाइल के साथ काम नहीं कर सकता और न ही करना चाहिए।

यदि आप गिट के लिए नए हैं, तो आपके पास विजुअल स्टूडियो प्रोजेक्ट्स पर आम तौर पर दूसरों की तुलना में एक अतिरिक्त कदम है क्योंकि आप बाइनरी फ़ाइल के साथ काम कर रहे हैं, न कि अजीब एक्सटेंशन वाले टेक्स्ट फाइलों के समूह वाले फ़ोल्डर्स का वास्तविक सेट। इसलिए आपको ACCDB फ़ाइल और आपके git रिपॉजिटरी को बनाने वाली टेक्स्ट फ़ाइलों के बीच अपने परिवर्तनों को लगातार निर्यात/आयात करने की आदत डालनी होगी।

आवश्यकताएं

आरंभ करने के लिए, हमें सॉफ़्टवेयर के 3 टुकड़े चाहिए:

1. विंडोज़ के लिए गिट
2. कछुआ गिट
3. OASIS-SVN

कड़ाई से बोलते हुए आपको दूसरे और तीसरे सॉफ़्टवेयर की आवश्यकता नहीं है। आप वास्तव में केवल पहले के साथ ही कर सकते हैं लेकिन बड़ा नकारात्मक पक्ष यह है कि आपको ऐसा करने के लिए अपना खुद का वीबीए मॉड्यूल लिखकर मैन्युअल रूप से निर्यात/आयात करना होगा और मेरा विश्वास करो, यह उन कारणों के लिए बहुत काम है जो स्पष्ट हो जाएंगे हम साथ चलते हैं। इस प्रकार, OASIS-SVN की दृढ़ता से अनुशंसा की जाती है। आपके पास TortoiseGit भी नहीं है, लेकिन मुझे वास्तव में काम करने में आसान बनाने के लिए GUI होना पसंद है। यह कुछ कमांड लाइन शुद्धतावादियों को अपमानित कर सकता है जो आपको बताएंगे कि आपको केवल कमांड लाइन में गिट का उपयोग करना चाहिए, न कि एक सुंदर जीयूआई के माध्यम से। हालाँकि, मुझे यह आलसी और त्वरित पसंद है और अधिकांश समय, प्रक्रिया सरल है कि मेरे लिए बस एक मेनू से कमांड निष्पादित करना एक बैश शेल खोलने और कुछ कमांड में टाइप करने की तुलना में तेज है। उस ने कहा, TortoiseGit वास्तव में git कमांड पर सिर्फ एक पतला आवरण है, इसलिए आपको इस बात पर पूरा ध्यान देना चाहिए कि यह किस git कमांड को चलाता है और इसका क्या अर्थ है।

उन सभी को स्थापित करें; विस्तृत निर्देशों के लिए मैं उनकी संबंधित वेबसाइटों को देखूंगा। एक बार यह सब सेट हो जाने के बाद, आपके पास एक प्रोजेक्ट होना चाहिए जिसे आप नियंत्रण में रखना चाहते हैं। इसके अलावा, आपको अपने अपस्ट्रीम रिपोजिटरी के रूप में कार्य करने के लिए एक स्थान की आवश्यकता है। हो सकता है कि आपके पास Azure DevOps खाता हो? बिट बकेट? गिटहब? आपके स्रोत कोड नियंत्रण को होस्ट करने के लिए आपके लिए कई विकल्प उपलब्ध हैं। बिल्ली, यदि आप इच्छुक हैं, तो आप एक निजी गिट सर्वर भी स्थापित कर सकते हैं। लेकिन वह भी लेख के दायरे से बाहर है। फिर से, मैं आपको रिक्त भंडार स्थापित करने के लिए संबंधित प्रदाता के दस्तावेज़ीकरण के लिए संदर्भित करता हूं।

एक बार जब आपके पास एक खाली भंडार हो, तो आपको इसका एक लिंक प्रदान किया जाना चाहिए। हम Auzre DevOps का उपयोग करते हैं, और हमने इस URL पर स्थित एक नया भंडार बनाया है:
https://samplecompany.visualstudio.com/DefaultCollection/z_Sandbox/_git/SampleApplication
अब जबकि हमारे पास एक रिक्त भंडार के लिए एक लिंक है, हम सेटअप प्राप्त कर सकते हैं।

स्थानीय भंडार बनाना

हालांकि ओएएसआईएस-एसवीएन में एक जादूगर है, मुझे मौजूदा भंडार को क्लोन करना और वहां से काम करना आसान लगता है। आप विज़ार्ड का उपयोग करने के लिए स्वतंत्र हैं जो कुछ ऐसा ही करेगा लेकिन मुझे लगता है कि मैन्युअल तरीके से अनुसरण करने से आपको यह समझने में मदद मिलेगी कि वास्तव में क्या हो रहा है और टूल के साथ काम करना आसान बना देगा। हम मान लेंगे कि हमारे पास एक विशेष फ़ोल्डर में एक एप्लिकेशन है:

स्रोत फ़ोल्डर खाली है और वह होगा जहां हम अपने स्थानीय भंडार के लिए पाठ फ़ाइलें रखेंगे। हम TortoiseGit . को खोलने के लिए फ़ोल्डर में सफेद स्थान पर राइट-क्लिक कर सकते हैं संदर्भ मेनू और क्लोन रिपॉजिटरी चुनें।

खुलने वाले संवाद में, अपने होस्टिंग प्रदाता से प्राप्त URL डालें:

ध्यान दें

फिर आपको एक सफल डायलॉग मिलना चाहिए कि रिपॉजिटरी को क्लोन कर दिया गया है:

क्लोनिंग के प्रभाव के रूप में, अब आपके पास .git . नाम का एक हिडन फोल्डर होगा . इस प्रकार git आपके कमिट और आपके स्थानीय रिपॉजिटरी में परिवर्तन का ट्रैक रखता है।

अब हमारे पास एक कार्यशील स्थानीय भंडार है जिसे हम एक्सेस से अपनी टेक्स्ट फ़ाइलों को रखने के लिए उपयोग कर सकते हैं। इसका उपयोग करने के लिए हमें OASIS-SVN को कॉन्फ़िगर करना होगा।

OASIS-SVN को कॉन्फ़िगर करना

जैसा कि पहले उल्लेख किया गया है, OASIS-SVN के पास एक विज़ार्ड है जिसका उपयोग हमें स्थापित करने के लिए किया जा सकता है लेकिन हम इसे मैन्युअल रूप से करना चाहते हैं ताकि आप OASIS-SVN के काम करने के तरीके से परिचित हों और इस प्रकार विज़ार्ड का प्रभावी ढंग से उपयोग कर सकें। हम सेटिंग . पर जाकर शुरुआत करेंगे OASIS-SVN रिबन टैब पर मेनू।

इससे डायलॉग खुल जाएगा। अभी के लिए, हमें केवल एक ही काम करने की जरूरत है; स्रोत पथ सेट करें। सामान्य तौर पर, मुझे निरपेक्ष पथ के बजाय सापेक्ष पथ का उपयोग करना अधिक सुविधाजनक लगता है, इसलिए हम \Source डालेंगे सचित्र के रूप में:

एक बार डालने के बाद, आपको चेकबॉक्स को चेक करना चाहिए हमेशा का उपयोग करें :

यह रिपोजिटरी फ़ोल्डर को सापेक्ष बनाता है और इस प्रकार आपको प्रोजेक्ट फ़ोल्डर को कहीं भी ले जाने की अनुमति देता है। लेकिन सावधान रहें - यदि आप एक्सेस फ़ाइल को उस फ़ोल्डर के बाहर कॉपी या स्थानांतरित करते हैं, तो इसे स्रोत कोड नियंत्रण में नहीं रखा जा सकता क्योंकि OASIS-SVN में .oasis नहीं होगा। फ़ाइल जिसे OASIS-SVN की आवश्यकता है। सेटिंग्स में परिवर्तनों को सहेजने के लिए संवाद को बंद करने के लिए ठीक क्लिक करें। यदि आप फ़ोल्डर में देखते हैं, तो अब आप .oasis . देखेंगे आपकी ACCDB फ़ाइल के लिए फ़ाइल।

.ओएसिस फ़ाइल केवल एक XML फ़ाइल है जिसमें सभी प्रोजेक्ट सेटिंग्स शामिल हैं, और इसका नाम ACCDB फ़ाइल के समान होना चाहिए ताकि OASIS-SVN को पता चले कि यह ACCDB फ़ाइल स्रोत कोड नियंत्रण में होनी चाहिए। इस प्रकार, यदि आप अपनी ACCDB फ़ाइल का नाम बदलने की आदत में हैं, तो आपको उस आदत को तोड़ने की आवश्यकता होगी। यदि आपके मौजूदा वर्कफ़्लो में फ़ाइल का नाम बदलना शामिल है, तो एक तरीका जो मुझे आसान लगता है, वह है डेवलपमेंट कॉपी के लिए एक निश्चित नाम का उपयोग करना (जैसे SampleApplication Dev.accdb , शायद), फिर जब मुझे नाम बदलने की आवश्यकता होती है, तो मैं उस फ़ाइल की एक प्रति बनाता हूं और उचित नाम प्रदान करता हूं। इस बात पर जोर दिया जाना चाहिए कि इसके साथ स्रोत कोड नियंत्रण में, संस्करणों का ट्रैक रखने के साधन के रूप में नाम बदलना अब कम समझ में आता है क्योंकि आपको अलग-अलग नामित प्रतियों का एक समूह होने के बजाय इसे गिट इतिहास से फिर से बनाने में सक्षम होना चाहिए।

शेष सेटिंग कॉन्फ़िगर करना

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

वस्तु प्रकार फलक

चूंकि हम अब एडीपी के साथ काम नहीं करते हैं और हम बहिष्कृत डेटा एक्सेस पेजों का उपयोग नहीं करते हैं, हम आम तौर पर आयात/निर्यात संवाद की अव्यवस्था को न्यूनतम रखने के लिए उन्हें अनचेक करते हैं। आपको ऑटो-चेंज को ऑटो-सेलेक्ट करना भी आसान लग सकता है, जिसके लिए ऑब्जेक्ट के टाइमस्टैम्प को ट्रैक करने की आवश्यकता होती है। हालाँकि, ध्यान रखें कि एक्सेस के भीतर ऑब्जेक्ट का टाइमस्टैम्प पूरी तरह से विश्वसनीय नहीं है। हम बाद के खंड में इस पर और चर्चा करेंगे। उस ने कहा, यह इंगित करने में मदद करने का एक अच्छा तरीका है कि क्या आप कोई आवारा वस्तु करना भूल गए हैं।

तालिका विकल्प फलक

इस फलक के लिए कुछ सावधान विचारों की आवश्यकता होगी और यह इस बात पर निर्भर करेगा कि आप किस प्रकार की परियोजनाओं से निपट रहे हैं। नंबर एक नियम यह है कि आप _not_ स्रोत कोड को अपनी तालिकाओं में डेटा को नियंत्रित करना चाहते हैं। इसका कोई मतलब नहीं है, क्योंकि डेटा कोड नहीं है। हालांकि, यह हमेशा सख्ती से सच नहीं होता है। उदाहरण के लिए, हमारे पास कई टेबल हैं जिनका उपयोग हम एप्लिकेशन कॉन्फ़िगरेशन डेटा के रूप में करते हैं। इस प्रकार, एक अर्थ में, वे टेबल "कोड" हैं क्योंकि वे प्रभावित करते हैं कि एप्लिकेशन कैसे काम करेगा। चूंकि हमारी अधिकांश परियोजनाएं SQL सर्वर बैकएंड के साथ एक्सेस फ्रंट-एंड हैं, जो टेबल आमतौर पर मौजूद होती हैं वे मुख्य रूप से केवल कॉन्फ़िगरेशन टेबल होती हैं और इस प्रकार स्रोत कोड नियंत्रण के लिए उपयुक्त होती हैं। लेकिन, अगर हमारे पास डेटा टेबल थे, तो शायद उन्हें शामिल नहीं किया जाना चाहिए। यहीं पर उन्नत बटन काम आता है। इसे क्लिक करने पर यह डायलॉग खुल जाएगा:

सभी तालिकाओं के लिए डेटा निर्यात करें . को अनचेक करके नीचे दिए गए चेकबॉक्स में, आप यह चुन सकते हैं कि आप किन तालिकाओं के डेटा को स्रोत कोड नियंत्रण में रखना चाहते हैं, उन तालिकाओं को छोड़कर जो केवल डेटा तालिका हैं और एप्लिकेशन स्रोत कोड का हिस्सा नहीं हैं।

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

सेटिंग फलक

हम इसे पहले ही देख चुके हैं जब हम .oasis . बना रहे थे फ़ाइल। अब जब हमारे पास फाइल है, तो हम बाकी सेटिंग्स को सेट कर देंगे। यह रहा हमारा सामान्य सेटअप।

जैसा कि मैंने शुरुआत में उल्लेख किया है, आप अपनी खुद की आयात/निर्यात दिनचर्या को निश्चित रूप से लिख सकते हैं। हालाँकि, OASIS-SVN का मूल्य यह है कि हम स्रोत कोड के तहत एक्सेस टेक्स्ट फ़ाइलों को रखने के साथ मौजूद विभिन्न मुद्दों को संबोधित कर सकते हैं। उदाहरण के लिए, किसी एक्सेस टेक्स्ट फ़ाइल में इसकी फ़ाइल के शीर्ष पर विशिष्ट फ़ील्ड हो सकते हैं:
Version =21
VersionRequired =20
PublishOption =1
Checksum =-571006847
Begin Form
...
End Form
वे स्रोत कोड नियंत्रण के लिए खराब हैं क्योंकि वे अनावश्यक परिवर्तन कर सकते हैं और उन परिवर्तनों के इतिहास को दूषित कर सकते हैं जो वास्तव में परिवर्तन नहीं हैं। चेकसम बदल सकता है, भले ही आपने वास्तव में फॉर्म के बारे में कुछ भी नहीं बदला हो। OASIS-SVN के साथ, हम निर्यात की गई फ़ाइलों को स्वच्छ करें विकल्प का उपयोग करके उस अनावश्यक डेटा को हटा सकते हैं :
Version =21
VersionRequired =20
Begin Form
...
End Form
आपने रिपोर्ट के लिए एक पीले रंग का चेतावनी आइकन देखा होगा। इसका कारण यह है कि OASIS-SVN प्रिंटर डेटा को भी हटा देगा जो स्रोत कोड नियंत्रण के लिए कुख्यात है। जब रिपोर्ट डिफ़ॉल्ट प्रिंटर का उपयोग करती है, तो यह आमतौर पर कोई समस्या नहीं होती है। हालाँकि, ऐसी रिपोर्ट बनाना असामान्य नहीं है जो किसी विशिष्ट प्रिंटर पर निर्भर करती हो। उदाहरण के लिए, हो सकता है कि हमारे पास एक रिपोर्ट हो जो किसी विशेष प्रिंटर पर बारकोड लेबल बना रही हो। उस रिपोर्ट में, हमने डिफ़ॉल्ट प्रिंटर के बजाय एक विशिष्ट प्रिंटर चुना होगा। रिपोर्ट के लिए उस बॉक्स को चेक करने का मतलब है कि प्रिंटर डेटा उड़ा दिया जाएगा। यदि आपका प्रोजेक्ट किसी विशेष प्रिंटर सेटअप पर निर्भर नहीं करता है, तो आपको रिपोर्ट्स की जांच करना आसान हो सकता है। अन्यथा, फ़ॉर्म के लिए इसकी जाँच न करने का कोई कारण नहीं है।

इसी तरह के कारणों के लिए, हम वास्तव में स्प्लिट फ़ॉर्म फ़ाइलें . रखना पसंद करते हैं और रिपोर्ट फ़ाइलें विभाजित करें विकल्प चेक किया गया। आम तौर पर, Application.SaveAsText एकल एक्सेस ऑब्जेक्ट के लिए सिंगल टेक्स्ट फ़ाइल निर्यात करेगा। हालाँकि, यदि आपने टेक्स्ट फ़ाइल पढ़ी है, तो आप देखेंगे कि लेआउट कोड ... पढ़ने में थकाऊ हो सकता है। इस विकल्प को चेक करने का मतलब है कि हमें प्रति एक्सेस ऑब्जेक्ट में 2 टेक्स्ट फाइलें मिलती हैं; एक में सभी लेआउट डेटा, और अन्य फॉर्म के पीछे वास्तविक वीबीए स्रोत कोड शामिल है। इससे कोड समीक्षा बहुत आसान हो जाती है क्योंकि आप VBA परिवर्तनों पर ध्यान केंद्रित कर सकते हैं और समझ सकते हैं कि क्या बदला है, जिससे लेआउट परिवर्तन के बारे में पचाना आसान हो जाता है।

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

एकीकरण फलक

हम आम तौर पर यह सुनिश्चित करना चाहते हैं कि ऑटो-करेक्ट हमेशा बंद रहे लेकिन निर्यात करने के लिए होकी के रूप में Ctrl + S का उपयोग करने का विकल्प अधिक महत्वपूर्ण है। यह बहुत मददगार है और एक्सेस ऑब्जेक्ट टाइमस्टैम्प के साथ समस्या से बचा जाता है। हालांकि, परिवर्तनों को सहेजने के लिए लगातार कीबोर्ड शॉर्टकट का उपयोग करने के लिए अनुशासन की आवश्यकता होती है। जब भी आप कीबोर्ड को निष्पादित करते हैं, तो आप संक्षेप में दिखाया गया यह डायलॉग देखेंगे:

यह सुनिश्चित करता है कि आपके git वर्किंग ट्री को आपकी कार्यशील ACCDB फ़ाइल के साथ सिंक में उतना ही करीब रखा जाए जितना आप परिवर्तनों के माध्यम से काम करते हैं। इस बात पर ज़ोर देना ज़रूरी है कि आपको बार-बार बचत करने में शर्माने की ज़रूरत नहीं है - इसका मतलब यह नहीं है कि आपको हर बचत करने की ज़रूरत है, लेकिन बार-बार बचत करने से, आपका काम करने वाला पेड़ आपके परिवर्तनों की सीमा को सटीक रूप से प्रतिबिंबित करेगा जब आप करने को तैयार हैं। हम इसके बारे में बाद के खंड में विस्तार से चर्चा करेंगे।

आयात से पहले स्वचालित अद्यतन और निर्यात के बाद स्वचालित COMMIT एक सुविधाजनक चीज की तरह लग सकता है, लेकिन व्यवहार में, हमने इसे मैन्युअल रूप से करना बहुत बेहतर पाया है, खासकर जब हम Ctrl + S शॉर्टकट के साथ निर्यात कर रहे हैं क्योंकि हम जरूरी नहीं करना चाहते हैं; केवल हमारे कार्य-प्रगति को बचाएं ताकि हम जान सकें कि जब हम वास्तव में प्रतिबद्ध होने के लिए तैयार होते हैं तो क्या बदल जाता है। इस कारण से, हम उन्हें छोड़ देते हैं।

.ओएसिस फ़ाइल सेट करना

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

निर्यात करना और प्रतिबद्ध करना

जैसा कि पहले ही उल्लेख किया गया है, क्योंकि हम एक बाइनरी फ़ाइल के साथ काम कर रहे हैं, हमें सब कुछ एक पाठ्य प्रतिनिधित्व में निर्यात करने की आवश्यकता है ताकि उन्हें स्रोत कोड नियंत्रण द्वारा ठीक से प्रबंधित किया जा सके। ऐसा करने के लिए, हमें वस्तुओं को निर्यात करने की आवश्यकता है। आप बताए अनुसार OASIS-SVN निर्यात बटन का उपयोग कर सकते हैं।

आपको निर्यात के लिए सूचीबद्ध सभी ऑब्जेक्ट प्रकारों के साथ एक संवाद मिलेगा। चूंकि यह हमारा पहला निर्यात है, इसलिए हम Ctrl + A . का उपयोग करेंगे निर्यात के लिए सभी का चयन करने के लिए।

निर्यात समाप्त करने के लिए ठीक क्लिक करें। यदि सब कुछ ठीक रहा, तो आपको ऐसा संकेत देने वाला एक संदेश प्राप्त होगा।

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

टेक्स्ट फ़ाइलों के रूप में निर्यात की गई वस्तुओं के साथ, अब हमें अपने परिवर्तन करने की आवश्यकता है। OASIS-SVN, TortoiseGit कमांड को सीधे एक्सेस के अंदर से प्रदान करता है जैसा कि दिखाया गया है।

आम तौर पर आप जिन 4 आदेशों का उपयोग करना चाहते हैं, उन्हें यहां दिखाया गया है - अन्य आदेश उपयोग करने के लिए अच्छे हैं लेकिन हमें इसके बारे में चिंता करने की आवश्यकता नहीं है जब तक कि हम अधिक जटिल गिट परिदृश्यों में नहीं आते। वैसे, वे आदेश वास्तव में वही आदेश हैं जो TortoiseGit द्वारा विंडोज एक्सप्लोरर के संदर्भ मेनू के माध्यम से उजागर किए जाते हैं:

इसके अलावा, एक्सेस नेविगेशन फलक पर राइट-क्लिक मेनू के माध्यम से कमांड का एक सबसेट उपलब्ध है:

इस प्रकार, आपके पास OASIS-SVN या TortoiseGit के साथ सीधे एक्सेस से बाहर काम करने के कई तरीके हैं, या आप सीधे Windows एक्सप्लोरर से TortotiseGit का उपयोग कर सकते हैं। ध्यान दें कि आपके पास प्रतिबद्ध . है सभी स्क्रीनशॉट में; जो हमारा अगला कदम होगा। इसे चुनने पर एक TortoiseGit डायलॉग खुलेगा:

आप आमतौर पर सभी का चयन करना चाहेंगे। ध्यान दें कि यह केवल उन टेक्स्ट फाइलों को ट्रैक करता है जिन्हें हम प्रोजेक्ट फ़ोल्डर में डालते हैं। वह बिंदु जोर देने लायक है; यदि आपने एक्सेस से किसी ऑब्जेक्ट को निर्यात नहीं किया है, तो गिट संभवतः इसके बारे में नहीं जान सकता है। आपको एक वर्णनात्मक प्रतिबद्ध संदेश प्रदान करने की आवश्यकता है; विस्तृत बेहतर। हम कई छोटे कमिट करना भी पसंद करते हैं क्योंकि इस तरह से इतिहास को समझना आसान होता है। आप सप्ताह में एक बार 1000 परिवर्तनों के साथ एक प्रतिबद्धता नहीं करना चाहते हैं; जिसे समझना असंभव होगा। किसी काम को पूरा करने के बाद आप एक कमिटमेंट चाहते हैं (उदाहरण के लिए किसी खास बग को ठीक करना, या किसी फीचर को शुरू करना), ताकि आपके इतिहास को आसानी से समझा जा सके।

जैसे ही आपको अपना काम करने की आदत हो जाती है, आप यह नोट करना चाहेंगे कि TortoiseGit आपको कमिट करने के लिए 3 विकल्प देता है:

सुझाव दें उपयोगी है यदि आपको कई कमिट करने की आवश्यकता है क्योंकि आपने 2 या अधिक कार्य किए हैं और आप प्रत्येक कार्य के लिए कमिट को अलग करना चाहते हैं। ऐसा न करना शायद सबसे अच्छा है और जैसे ही आप किसी कार्य को पूरा करते हैं, लेकिन यदि आप उत्साह में फंस जाते हैं, तो आप केवल उन फाइलों के एक सबसेट की जांच करते हैं जिन्हें आप करना चाहते हैं और फिर से क्लिक करें। TortoiseGit केवल उन सबसेट फ़ाइलों को प्रतिबद्ध करेगा, फिर प्रतिबद्ध संवाद को रीसेट करें ताकि आप फ़ाइलों के अन्य सबसेट को एक अलग संदेश के साथ कर सकें।

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

जब आप प्रतिबद्ध होते हैं, तो TortoiseGit आपको एक प्रगति संवाद प्रदान करेगा, और सफल होने पर आपको सूचित करेगा।

रैपिंग अप

अब तक आपने सीखा है कि git रिपॉजिटरी कैसे सेट करें, OASIS कॉन्फ़िगर करें और अपना पहला कमिट करें। हालाँकि, यह मुश्किल से सतह को खरोंच रहा है। गिट की पूरी शक्ति अभी तक स्पष्ट नहीं है जब तक आप शाखाओं में नहीं आते, इतिहास पढ़ रहे हैं और संघर्षों को हल कर रहे हैं। हालांकि, वे सख्ती से गिट चीजें हैं और एक्सेस या ओएएसआईएस के साथ कम करना है; कोई भी सामान्य git गाइड जिसे हमने पहले ही लेख की शुरुआत में लिंक किया था, यह समझने में बहुत मददगार होगा कि git रिपॉजिटरी को कैसे प्रबंधित किया जाए। यह याद दिलाने लायक है कि TortoiseGit git कमांड पर सिर्फ एक पतला GUI आवरण है, इसलिए भले ही ट्यूटोरियल बैश शेल का उपयोग करने के बारे में बात करता हो, आपको समान नाम वाले TortoiseGit मेनू के माध्यम से वही काम करने में सक्षम होना चाहिए। कोई सवाल? टिप्पणियों में पूछें!