आर के लिए "वर्कफ़्लो" के साथ आप "संशोधन नियंत्रण" को कैसे जोड़ते हैं?

Question

मुझे याद है कि आर उपयोगकर्ताओं को यह कहते हुए कि वे "संशोधन नियंत्रण" (e.g: "Source control") का उपयोग करते हैं, और मुझे यह जानकर उत्सुकता है: आप अपने सांख्यिकीय विश्लेषण वर्कफ़्लो के साथ "संशोधन नियंत्रण" कैसे जोड़ते हैं?

दो (बहुत) रोचक चर्चाएं वर्कफ़्लो से निपटने के तरीके के बारे में बात करती हैं। लेकिन उनमें से कोई भी संशोधन नियंत्रण तत्व का संदर्भ लें:

• How to organize large R programs?
• Workflow for statistical analysis and report writing

प्रश्न करने के लिए एक लंबे समय से अपडेट: टिप्पणी में लोगों की कुछ उत्तर, और एक प्रकार की कटार के सवाल के बाद , मैं अपने प्रश्न को थोड़ा और निर्देशित करना चाहता हूं।

"revision control" के बारे में विकी लेख (जो मैं पहले से परिचित नहीं था) को पढ़ने के बाद, यह मेरे लिए स्पष्ट था कि संशोधन नियंत्रण का उपयोग करते समय, क्या नहीं करता उसके कोड का एक विकास संरचना निर्माण करना है। यह संरचना या तो "अंतिम उत्पाद" या कई शाखाओं की ओर ले जाती है।

कुछ ऐसा बनाते समय, एक वेबसाइट कहें। आमतौर पर एक अंत उत्पाद होता है जो आप (वेबसाइट) की ओर काम करते हैं, जिस तरह से कुछ प्रोटोटाइप होते हैं।

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

यही कारण है कि सांख्यिकीय प्रोग्रामिंग के साथ कार्यप्रवाह सवाल है, एक गंभीर और गहरी सवाल (मेरे विचार में) है कई मुद्दों को उठाने, सरल लोगों तकनीकी कर रहे हैं:

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

कैसे आप इस तनाव को हल करने के लिए मेरी प्रारंभिक जिज्ञासा थी। दूसरा सवाल यह है कि "मैं क्या खो सकता हूं?"। संस्करण नियंत्रण के साथ सांख्यिकीय प्रोग्रामिंग कर रहे सामान्य नुकसान से बचने के लिए किस नियम (अंगूठे) का पालन करना चाहिए?

मेरे अंतर्ज्ञान में, मुझे लगता है कि सांख्यिकीय प्रोग्रामिंग स्वाभाविक रूप से अलग है, तो सॉफ्टवेयर विकास (मैं सांख्यिकीय प्रोग्रामिंग में एक वास्तविक विशेषज्ञ होने के बिना इसे लिख रहा हूं, और सॉफ्टवेयर विकास में भी कम है)। इस तरह से मैं अनिश्चित हूं कि संस्करण नियंत्रण के बारे में मैंने जो सबक पढ़ा है, वह लागू होगा।

धन्यवाद एक बहुत, ताल

Answer 1

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

मैं एक्लिप्स + स्टेटेट का उपयोग करता हूं और जबकि ग्रहण (EGit और शायद अन्य) में गिट के लिए प्लगइन है, तो मैं इसका उपयोग नहीं करता हूं। मैं विंडोज़ में हूं और विंडोज के लिए गिट-गुई का उपयोग करें। यहां some more options है।

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

यह भी ध्यान रखें कि संस्करण नियंत्रण अच्छी बैकअप योजना के लिए कोई प्रतिस्थापन नहीं है। मेरा आदर्श वाक्य है: "3 प्रतियां। 2 भौगोलिक। शांति पर 1 दिमाग।"

संपादित करें (फरवरी 24, 2010): योएल Spolsky, स्टैक ओवरफ़्लो के संस्थापकों में से एक है, बस एक highly visual and very cool intro to Mercurial का विमोचन किया। यदि आप पहले से ही संशोधन नियंत्रण प्रणाली नहीं चुना है तो यह ट्यूटोरियल Mercurial को अपनाने का कारण हो सकता है। मुझे लगता है कि जब गिट बनाम Mercurial की बात आती है तो सबसे महत्वपूर्ण सलाह है कि वह किसी को चुना जाए और इसका इस्तेमाल करें। शायद अपने दोस्तों/सहकर्मियों का उपयोग करें या सबसे अच्छे ट्यूटोरियल के साथ उपयोग करें। लेकिन बस पहले से ही एक का उपयोग करें! ;)

Answer 2

मैं संस्करण नियंत्रण के लिए Git उपयोग कर रहा हूँ। मेरी सामान्य निर्देशिका संरचना (उदाहरण के लिए लेखों के लिए) निम्नानुसार है।

. 
.. 
.git 
README 
README.html 
ana 
dat 
doc 
org 

अधिकांश निर्देशिका/फ़ाइलें (एना, डॉक्टर, संगठन) संस्करण नियंत्रण में हैं। बेशक, बड़े बाइनरी डेटासेट को संस्करण नियंत्रण (.gitignore के माध्यम से) से बाहर रखा गया है। रीडमेम एक Emacs संगठन मोड फ़ाइल है।

Answer 3

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

यदि मुझे अतिरिक्त बैकअप आश्वासन की आवश्यकता है, तो मैं रिमोट (सुरक्षित!) भंडार को गिट कर सकता हूं।

-Wil

Answer 4

विशेष रूप से संशोधन नियंत्रण पर ध्यान केंद्रित करने की बजाय, ऐसा लगता है कि आप वास्तव में सांख्यिकीय विश्लेषण की तुलना में सांख्यिकीय विश्लेषण की तुलना में एक बड़ा सवाल पूछ रहे हैं। यह एक दिलचस्प सवाल है। यहां कुछ विचार दिए गए हैं:

डेटा विश्लेषण विज्ञान से अधिक कला की तरह हो सकता है। एक अर्थ में, हो सकता है कि आप इस प्रक्रिया के लिए प्रेरणा की तलाश कर सकें कि एक लेखक डेवलपर का पालन करने वाली प्रक्रिया से अधिक पुस्तक लिखते समय एक लेखक का पालन करेगा। दूसरी तरफ, मुझे अभी तक एक सॉफ्टवेयर परियोजना का सामना करना पड़ेगा जो सीधी रेखा का पालन करता है।और यहां तक ​​कि एक सैद्धांतिक स्तर पर, software development methodologies में भिन्नता है। इनमें से, एक सांख्यिकीय विश्लेषण एक खोज प्रक्रिया हो सकती है (यानी एक जिसे पूरी तरह से आगे की योजना नहीं बनाई जा सकती है), agile methodology (कुछ और भी है कि झरना पद्धति की तरह कुछ) का पालन करना समझदारी होगी। दूसरे शब्दों में, आपको अपने विश्लेषण के लिए पुनरावृत्ति और आत्म-प्रतिबिंबित होने की योजना बनाने की आवश्यकता है।

उस ने कहा, मुझे लगता है कि सांख्यिकीय विश्लेषण पूरी तरह से दिमाग में कोई लक्ष्य नहीं है, यह संभवतः समस्याग्रस्त है। इससे उस बिंदु तक पहुंचा जा सकता है जहां आप अपने यूरेका पल से 5 कदम हैं, और इसके पास वापस आने का कोई तरीका नहीं है। हमेशा कुछ प्रकार का लक्ष्य होता है, भले ही लक्ष्य स्वयं बदल रहा हो। इसके अलावा, यदि कोई लक्ष्य नहीं है, तो आप अंत तक पहुंचने पर कैसे जानेंगे?

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

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

आपको यह भी गंभीर विचार करना चाहिए कि आपके आस-पास के अन्य लोग क्या कर रहे हैं। कुछ भी मुझे पहिया को फिर से शुरू करने के लिए लोगों को देखने से ज्यादा परेशान नहीं करता है, खासकर जब इसका मतलब समूह के लिए पूरी तरह से एकीकृत करने के लिए अतिरिक्त काम है।

समग्र परियोजना प्रबंधन के संबंध में टोटेम ध्रुव पर अंततः कौन सा संस्करण नियंत्रण प्रणाली उपयोग करने के लिए आपके संस्करण नियंत्रण प्रणाली, कार्यान्वयन के मुद्दे) बहुत कम हैं। बस का उपयोग करें उनमें से एक ठीक से और आप पहले से ही 95% रास्ते में हैं, और कुछ भी उपयोग करने के विकल्प की तुलना में उनके बीच अंतर छोटे हैं।

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

Answer 5

अपने अद्यतन पढ़ने के बाद, ऐसा लगता है आप संरचना अपने भंडार का और कार्यप्रवाह हुक्म के रूप में चुनाव और एक संस्करण नियंत्रण प्रणाली के उपयोग को देख रहे हैं की तरह।

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

2. सभी पूर्ववत बटनों की मां। क्या विश्लेषण एक घंटे पहले बेहतर दिख रहा था? एक दिन पहले? एक हफ्ते पहले?संस्करण नियंत्रण एक रिवाइंड बटन प्रदान करता है जो आपको समय पर वापस यात्रा करने की अनुमति देता है।

यदि आप एक परियोजना पर काम कर रहे एकमात्र व्यक्ति हैं, तो उपरोक्त दो बिंदु शायद यह बताते हैं कि संस्करण नियंत्रण प्रणाली आपके काम के तरीके को कैसे प्रभावित करेगी।

संस्करण नियंत्रण प्रणाली का दूसरा पक्ष यह है कि वे लोगों को परियोजना सामग्री के एक पृथक प्रति या "शाखा" पर प्रयोग करने की अनुमति देकर सहयोगी प्रयासों को बढ़ावा देते हैं और फिर मास्टर कॉपी में किसी भी सकारात्मक परिवर्तन को "विलय" करते हैं। यह प्रोजेक्ट सदस्यों के लिए टैबों को रखने के लिए एक साधन भी प्रदान करता है कि किसके बदलावों से प्रभावित फाइलें हैं।

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

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

महत्वपूर्ण मुद्दा यह है कि इन मामलों मेरी भंडार की संरचना और कार्यप्रवाह मैं का उपयोग अपने संस्करण नियंत्रण द्वारा तय नहीं कर रहे हैं दोनों में system-- वे मेरे द्वारा निर्णय लिया जाता है। मेरे वर्कफ़्लो पर संस्करण नियंत्रण का एकमात्र प्रभाव यह है कि यह मुझे कुछ नया करने की कोशिश करने से चिंतित होने से मुक्त करता है, यह तय करता है कि मुझे यह पसंद नहीं है, और फिर मैंने जहां शुरू किया था, वहां वापस आने के लिए सभी परिवर्तनों को पूर्ववत करना होगा। क्योंकि मैं संस्करण नियंत्रण का उपयोग करें, मैं योगी Berra की सलाह का पालन कर सकते हैं:

आप सड़क में एक कांटा के लिए आते हैं, इसे ले।

क्योंकि मैं हमेशा वापस जा सकता हूं और इसे दूसरी तरफ ले सकता हूं।