2010-03-31 10 views
8

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

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

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

इसका यह भी अर्थ है कि, यह नहीं है कि एक टीम लीड उन सभी अच्छे एसवीएन प्रतिबद्ध ईमेल को नहीं देख सकती है ताकि कोड-बेस में क्या हो रहा है?

क्या यह कोई वास्तविक मुद्दा है?

+0

आपको बैकअप समाधान की आवश्यकता क्यों होगी? आपके पास पहले से डेवलपर के कंप्यूटर पर कोड की एक प्रति है। –

+3

क्या आप? निश्चित रूप से पूरा बिंदु यह है कि आप तैयार होने पर केवल अपने परिवर्तन किसी और को धक्का देते हैं? यह 2 सप्ताह का काम या अधिक हो सकता है जो केवल आपके पीसी पर मौजूद है। –

उत्तर

2

मैं कर सकते हैं एक बार उनके स्थानीय अंतर समाप्त होने के बाद बैकअप भूलने वाले देवताओं के बारे में आपकी चिंता को समझें (क्योंकि उन्होंने स्थानीय रूप से किया है) और उन्हें अत्यधिक आउटपुट के साथ नाराज करना बंद कर देता है। मुझे लगता है कि समाधान बेहतर उपकरण, मोर टूल्स में झूठ बोल सकता है! आप प्रत्येक देव के बॉक्स पर एक क्रॉन नौकरी स्थापित कर सकते हैं जो केंद्रीय रिपो में अपने भंडार में हर अंतिम पहुंच योग्य वस्तु को धक्का देता है, और उन्हें नामित शाखाओं के साथ केंद्रीय (बैक-अप) रेपो में लेबल करता है। मुझे लगता है कि "गिट पुश" सही रेफस्पेक दिए जाने पर ऐसा कर सकता है। फिर, आप जो भी नहीं कर रहे हैं वह आपकी सार्वजनिक शाखाओं की स्थिति को प्रभावित कर रहा है।

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

+1

यह मेरे लिए बिल्कुल गलत लगता है ....पुराने केंद्रीकृत संस्करण के तहत, पूर्ण स्रोत पेड़ कई स्थानों पर मौजूद था, क्योंकि उपयोग मॉडल को बहुत से नियमित अपडेट/काम करने की आवश्यकता होती है। लेकिन विघटित मॉडल में, जैसा कि जॉन कहते हैं, डेवलपर्स काम पीसी पर केवल हफ्तों के लायक काम उपलब्ध हो सकते हैं। – Clyde

+0

हां, प्रश्न _A_ को केंद्रीय प्रतिलिपि बनाने के बारे में नहीं है। यह विशेष रूप से काम के बारे में है जो स्थानीय रूप से प्रतिबद्ध है लेकिन धक्का नहीं दिया जाता है - एसवीएन/सीवीएस के साथ आप जानते हैं कि क्या आप इसे अपने स्थानीय पीसी –

+2

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

0

भंडार की स्थानीय प्रतिलिपि होने से खराब बैकअप आदतों को प्रोत्साहित किया जा सकता है, अगर कोई ढीला हो। हालांकि, आपके मास्टर भंडार का समर्थन किया जाना चाहिए।

"संपूर्ण भंडार की स्थानीय प्रति" बैकअप होने से कहीं अधिक महत्वपूर्ण उपयोग है। यह कोडबेस के इतिहास की जांच करने की विलम्ब को कम करता है - कहें, नवीनतम संस्करण के खिलाफ भिन्नता - अपने स्थानीय हार्ड ड्राइव की यात्रा के लिए नेटवर्क राउंड ट्रिप होने से।

यदि आपके मुख्य भंडार आपके गिगाबिट लैन पर है तो यह इतना बड़ा सौदा नहीं लगता है। यदि आप एक दूरसंचार हैं, और एक वीपीएन पर भंडार 600+ एमएस दूर है, तो यह अंतर की दुनिया बनाता है।

मैंने इसे कभी नहीं देखा है, लेकिन मुझे यकीन है कि Mercurial और Git दोनों पोस्ट-प्रतिबद्ध हुक का समर्थन करते हैं, जिससे आप टीम लीड पर जाने वाले प्रतिबद्ध मेल सेट कर सकते हैं। फिर प्रत्येक डेवलपर तदनुसार अपना भंडार स्थापित कर सकता है, या एक अंतरिम भंडार है जो प्रतिबद्ध मेल के साथ अर्ध-बेक्ड सुविधाओं की अनुमति देता है, या जो भी हो।

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

+0

यदि आप धीमे रिमोट कनेक्शन पर हैं तो यह diffs के लिए अच्छा है, लेकिन मैं इस तरह से एक संपूर्ण भंडार डाउनलोड करने से नफरत करता हूं! धीमी कनेक्शन पर –

+0

एक संपूर्ण भंडार डाउनलोड करना परेशान है, लेकिन आपको केवल एक बार ऐसा करने की आवश्यकता है। यदि आप घर से काम कर रहे हैं, तो आप शॉवर और नाश्ते से पहले बड़ी खींच शुरू कर सकते हैं (या रात पहले बिस्तर पर, अगर यह वास्तव में बड़ा है)। उसके बाद, आप केवल छोटे diffs खींच और धक्का। – Wilka

+0

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

1

मुझे नहीं लगता कि आपके पास इस पर automatism है। वितरित या केंद्रीकृत वीसीएस बैकअप (या नहीं) के साथ जोड़ा जा सकता है। यह टीम में अनुशासन का एक सवाल है।

प्रतिबद्ध-ईमेल के लिए ही। यदि टीम को सही भंडारों में नियमित रूप से परिवर्तन करने के लिए अनुशासन है, तो आप भी एक कार्यशील प्रतिबद्धता-मेलिंग सूची कर सकते हैं।

केंद्रीकृत वीसीएस के साथ एक टीम में बुरी आदतें भी बढ़ सकती हैं। आप हमेशा बुरी आदतों से लड़ने के लिए है।

0

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

यह एक प्रबंधन समस्या भी है - अपनी टीम को बताएं - नियमित रूप से दबाएं (कम से कम दैनिक) ताकि आपका कोड बैक अप हो। यदि यह नहीं किया जा रहा है, तो बड़ी छड़ी बाहर निकलें।

मैं यह भी ध्यान रखें चाहते हैं, कि अगर आप को देखने के लिए क्या अपने कर्मचारियों को क्या कर रहे हैं प्रतिबद्ध को देखकर पर भरोसा कर रहे हैं, तो आप शायद कुछ बड़े मुद्दों है कि आप को संबोधित करने लग सकता है ...

+1

"अपनी टीम को बताएं - नियमित रूप से धक्का दें" ... हाँ, लेकिन मेरी बात यह है कि यह करने के लिए एक और चीज पेश करती है। एक बड़ी छड़ी अच्छी तरह से अच्छी और अच्छी है, लेकिन जितना अधिक याद रखना है, उतना ही अधिक संभावनाएं हैं। छुट्टी पर जाने वाले देव की तरह खुश उन्होंने कोड में चेक किया है लेकिन केंद्रीय रेपो को धक्का देना भूल जाता है। –

+0

"आपके पास शायद कुछ बड़े मुद्दे हैं" ... हां, लेकिन विशेष रूप से दूरस्थ टीमों पर यह एक तकनीकी नेतृत्व के रूप में अधिक 'संपर्क में' रखने का एक तरीका है, केवल डेवलपर्स से बात करने के बजाय कि उन्होंने क्या किया है। एक बड़ी बात नहीं, एक छोटी सी झुकाव। –

+0

@ जॉन - मुझे लगता है कि आपको उचित रूप से प्रशिक्षित होने पर, अपनी देव टीम पर भरोसा करने में सक्षम होना चाहिए। जो व्यक्ति छुट्टी पर जाता है उसे फिर से होने के खिलाफ कम करने के लिए उसकी वापसी पर पर्याप्त शर्मिंदा होना चाहिए। मुझे लगता है कि लाभ संभावित लागत से अधिक है। – Paddy

संबंधित मुद्दे

 संबंधित मुद्दे