एसवीएन गिट से बेहतर क्या करता है? [बन्द है]

Question

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

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

क्या यह वास्तव में संस्करण-नियंत्रण प्रणालियों (VCS) के साथ मामला है, विशेष रूप से, केंद्रीकृत VCS ( CVS और SVN ) बनाम वितरित VCS ( Git और Mercurial )?

मैंने एसवीएन का उपयोग लगभग पांच वर्षों के लिए किया था, और एसवीएन वर्तमान में उपयोग किया जाता है जहां मैं काम करता हूं। तीन साल पहले की तुलना में थोड़ा कम, मैंने अपने सभी व्यक्तिगत प्रोजेक्ट्स के लिए Git (और GitHub) पर स्विच किया।

मैं तोड़फोड़ पर लाभ के कई लाभों के बारे में सोच सकता हूं (और जो कि केंद्रीकृत वीसीएस पर वितरित के फायदे के लिए सबसे अधिक सार है), लेकिन मैं एक भी उदाहरण के बारे में नहीं सोच सकता - कुछ कार्य (जो प्रासंगिक हैं और एक प्रोग्रामर में सामान्य रूप से उत्पन्न होते हैं कार्यप्रवाह) कि तोड़फोड़ Git से बेहतर है।

इसका एकमात्र निष्कर्ष यह है कि मेरे पास कोई डेटा नहीं है - ऐसा नहीं है कि Git बेहतर है, आदि।

मेरा अनुमान है कि इस तरह के प्रति-उदाहरण मौजूद हैं, इसलिए यह सवाल है।

Comments

@ जोकून: किसके संदर्भ में कुशल? स्थानीय संचालन की तुलना में निश्चित रूप से तेज ईथरनेट भी धीमा नहीं है।

— माआर्टिनस

यह देखें StackOverflow Q: SVN का उपयोग क्यों करें? कोई छिपा हुआ मुकदमा (GIT / Mercurial / Bazaar पर)?

— detly

मैंने हमेशा सोचा है कि गिट अत्यधिक सम्मानित था। यह एक सनक है, और प्रोग्रामर सनक के लिए अभेद्य नहीं हैं - इस विचार के कई विरोधों के बावजूद। इस दुनिया में हर किसी की तरह, हर कोई चमकदार नया खिलौना (Git) चाहता है । Git कुछ लोगों के लिए अच्छा हो सकता है - या यहां तक ​​कि महान भी हो सकता है - लेकिन यह वस्तुनिष्ठ रूप से सोचते समय SVN से बेहतर नहीं है ।

— 777

मैंने सोचा कि एसवीएन अभी भी उपयोग करने के लिए अच्छा है, सीखने की अवस्था अच्छी है फिर जीआईटी।

— चेउंग

यह सवाल हाल ही में मुख्य रूप से आधारित राय के रूप में रखा गया था। वह वर्गीकरण गलत है; ध्यान दें कि प्रश्न लंबे समय तक खुला था; डीवीसीएस के गुणों के बारे में कई सवाल हैं, और यह सवाल यह नहीं पूछता है कि क्या यह बेहतर है (राय), लेकिन यह बेहतर क्या है। मतभेद राय नहीं है, लेकिन क्या समग्र उत्पाद है - यह मुश्किल है (लेकिन इस सवाल का मुद्दा नहीं है)।

— Eamon Nerbonne

Answer 1

तोड़फोड़ एक केंद्रीय भंडार है

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

तोड़फोड़ पारंपरिक ज्ञान है

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

तोड़फोड़ इसे एक तरह से करता है, और कुछ नहीं

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

अन्य फायदे हैं:

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

Comments

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

— दान रे

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

— पॉल टॉम्बलिन

Git का उपयोग केंद्रीकृत तरीके से क्यों नहीं किया जा सकता है? बस एक केंद्रीय रिपॉजिटरी है, और आपके देवता क्लोन कर सकते हैं और खींच सकते हैं और धक्का दे सकते हैं जैसे वे चेकआउट करते हैं और अपडेट करते हैं और प्रतिबद्ध होते हैं।

— डेविड थॉर्नले

@PaTTomblin - वर्कफ़्लो के आधार पर, Git बेहतर बैकअप प्रदान कर सकता है । उदाहरण के लिए, हम निजी जीथब रिपोज का उपयोग करते हैं और मैं अक्सर अपने कोड को फीचर शाखाओं तक धकेलता हूं। यदि मेरे सहकर्मी करते हैं git fetch origin, तो उनमें से प्रत्येक के पास मेरे कोड का बैकअप है, साथ ही जो कुछ भी बैकअप Github स्वयं प्रदान करता है। (हम नियमित रूप से विलय की शाखाओं को, स्थानीय रूप से और गितुब दोनों को मिलाते हैं।)

— नाथन लॉन्ग

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

— जॉन फिशर

Answer 2

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

और एक छोटा सा लाभ: तोड़फोड़ खाली निर्देशिकाओं को ट्रैक कर सकती है। Git फ़ाइल सामग्री को ट्रैक करता है, इसलिए बिना किसी फ़ाइल के कोई निर्देशिका दिखाई नहीं देगी।

Comments

उप पेड़ों के साथ काम करना IMHO केवल एक चीज है जो एसवीएन ने जीआईटी से अधिक है। बिंदु लिया, खाली निर्देशिका अच्छी है, लेकिन आवश्यक नहीं है (और चारों ओर काम किया जा सकता है)। अगर git सबमॉड्यूल्स और git सबट्री कम भ्रमित होते हैं तो बहुत से लोगों को GIT में जाने से रोकने के लिए कुछ भी नहीं होगा। अन्य लाभ कुछ लोगों ने उल्लेख किया है (डेवलपर) मानसिकता। जैसे अगर आपको ऊपर से नीचे तक की जरूरत है, तो ठीक है। हालांकि आपके लिए मेरे पास कोई काम नहीं होगा।

— तक

यह हास्यास्पद है कि ये किस प्रकार की चीजें हैं जो एसवीएन (और अन्य केंद्रीकृत संस्करण नियंत्रण) के पक्ष में तर्क दे सकते हैं

— ड्यूकफैग्मिंग

यह अजीब क्यों है? - पुराने सिस्टम से नए सिस्टम सीखते हैं। आरसीएस ऑन गिट के साथ एक लाभ भी है: इतिहास की फाइलें आसानी से हाथ से संपादित की जा सकती हैं और आपके पास प्रति-फ़ाइल शाखाएं हो सकती हैं। लेकिन इवोल्यूशन में यह शामिल है कि सुविधाएँ खो जाती हैं ...

— जोहान्स

मैंने एक गेम कंपनी के बारे में सुना है जो एसवीएन को जीआईटी से अधिक इस कारण से उपयोग करती है - जब आपकी रिपॉजिटरी आकार में कई जीबी के बारे में बात करती है, तो यह अचानक महत्वपूर्ण हो जाता है!

— जेम्स

Git संस्करण 1.8.0 के रूप में, अब आप इसे git subtreeठीक से पूरा करने के लिए कमांड का उपयोग कर सकते हैं । अंतिम तोड़फोड़ का फायदा धूल को काटता है :) यहाँ विवरण: github.com/gitster/git/blob/… नोट: भले ही यह एक गितुब परियोजना की एक कड़ी है, git-subtree अब कोर गिट वितरण का हिस्सा है।

— कार्ल

Answer 3

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

यह कहना नहीं है कि हम सभी विकास को Mercurial पर नहीं ले जा रहे हैं।

Comments

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

— 11

@ हॉकिंग: मुझे एसवीएन पसंद नहीं है, लेकिन अगर कोई मुझसे कहता है "मुझे ये नई डीवीसीएस चीजें पसंद नहीं हैं, तो मैं सीवीएस के साथ रहूंगा", तो मैं निश्चित रूप से इसकी सिफारिश करूंगा : यह कम से कम आसान रास्ता है आंशिक रूप से समझदार वीसीएस ;-)

— जोकिम सॉयर

नए तरीके हमेशा हर परिस्थिति के लिए सबसे अच्छे नहीं होते हैं। यह नासा के बारे में पुरानी कहानी को ध्यान में रखते हुए लाखों डॉलर खर्च कर एक पेन विकसित कर रहा है जो 0 जी में लिख सकता है। दूसरी ओर कास्मोनॉट्स पेंसिल की वजह से बना। कभी-कभी पुराने तरीके बेहतर होते हैं, अब मेरे पास जाओ!

— maple_shaft

@maple_shaft, और कभी-कभी वे नहीं होते हैं। snopes.com/business/genius/spacepen.asp

— पीटर टेलर

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

— वारेनटी

Answer 4

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

Comments

क्या आपका दिमाग नहीं टूटता? मुझे एसवीएन में संघर्ष के साथ आसानी से शाखाओं का विलय कैसे करना है?

— वारेनटी

"बेहतर" उपकरण / सामने के छोर, यह एक चलती लक्ष्य है। दोनों तरफ उपकरण सुधरते हैं। हम में से कोई भी नहीं जानता कि अब से कई साल बाद कौन से उपकरण उपलब्ध होंगे। 10 महीने पहले का मूल्यांकन समय के साथ आसानी से बदल सकता है, और अब बासी हो सकता है। मैं ठोस जवाब देखना पसंद करूंगा।

— वारेनटी

वृक्षों का टकराव? चेक। सभी विकल्पों के लिए हाँ या नहीं? सं Svn को घुसपैठ करने के लिए डिज़ाइन किया गया है। क्लीन वर्किंग कॉपी कमांड? नहीं उलटा फ़ाइलों को साफ नहीं कर सकते।

— वॉरेन पी

सब कुछ हटाने और फिर से बाहर की जाँच की गई फ़ाइलों को हटा दिया जाएगा।

— jgmjgm

मुझे आपका अंतिम विचार अच्छा लगा, Git ने मेरा दिमाग तोड़ दिया: '(

— ल्यूक

Answer 5

मैंने इसे किसी और के उत्तर पर एक टिप्पणी के रूप में लिखा था, लेकिन मुझे लगता है कि यह खुद में और उत्तर के योग्य है।

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

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

Comments

केंद्रीयता मिथक का विषय है, तथ्य का नहीं। मुझे कुछ भी बदलने से कोई नहीं रोक सकता। एक सीवीसी के साथ वे मुझे कुछ बदलने से रोक सकते हैं। एक dvcs में एक ही बात। शब्द cvcs में प्रतिबद्ध प्रतिबद्ध और धक्का देता है।

— वॉरेन पी

@ जोनाथन हेंसन: निश्चित रूप से एकमात्र कारण नहीं है जो टॉर्वाल्ड एसवीएन से नफरत करता है। एसवीएन केंद्रीकृत हो सकता है और एक बेहतर सीवीएस हो सकता है लेकिन यह शायद ही एक अच्छा सॉफ्टवेयर बनाता है। Torvalds को CVS / SVN से नफरत है क्योंकि वे केंद्रीकृत नहीं हैं, बल्कि इसलिए कि वे मानते हैं कि वे pathetically खराब सॉफ्टवेयर हैं। वह सही है या नहीं यह तय करना आपके लिए है, लेकिन दोनों लिनक्स (और एंड्रॉइड) की भारी सफलता को देखा - अरबों उपकरणों पर - और Git - जो बहुत तूफान द्वारा दुनिया को ले जा रहा है--, मैं ' d उससे असहमत होने से पहले दो बार सोचें। Toritds ने Google पर Git पर सालों पहले जो व्याख्यान दिया वह अद्भुत है।

— सेड्रिक मार्टिन

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

— gbjbaanb

Answer 6

मेरे कारण:

• परिपक्वता - दोनों सर्वर, और उपकरण (जैसे TortoiseSVN)
• सादगी - कम कदम शामिल, एक प्रतिबद्ध एक प्रतिबद्धता है। DVCS जैसे Git और Mercurial शामिल होते हैं, फिर धक्का देते हैं।
• बाइनरी हैंडलिंग - एसवीएन बाइनरी एक्जीक्यूटिव और इमेज को Git / Hg से बेहतर तरीके से हैंडल करता है। विशेष रूप से उपयोगी। NET परियोजनाओं के साथ क्योंकि मैं स्रोत नियंत्रण में निर्माण से संबंधित उपकरणों की जांच करना चाहता हूं।
• नंबरिंग - एसवीएन के पास एक पठनीय प्रतिबद्ध नंबरिंग योजना है, केवल अंकों का उपयोग करके - संशोधन संख्याओं को ट्रैक करना आसान है। Git और Hg इसे काफी अलग तरीके से करते हैं।

Comments

"प्रतिबद्ध संख्या योजना" केवल तभी संभव है जब आपके पास विहित चड्डी हों। अन्यथा कौन सी नंबरिंग मिलती है?

+1 svn में सुन्न। यह संख्या अद्वितीय है। ऐप-वर्जनबोर xx.yy.zz.12882 के हिस्से के रूप में इस नंबर का उपयोग करने के लिए उपकरण हैं जहां 12882 svn संस्करण-संख्या है। अगर कोई उत्पादन समस्या है, तो आप वर्जनबोर को पूछ सकते हैं और आपके पास सटीक svn-revision है जहां सॉफ्टवेयर का निर्माण किया गया था

— k3b

Answer 7

मैं सराहना करता हूं कि आप अच्छी जानकारी की तलाश कर रहे हैं, लेकिन इस तरह का प्रश्न सिर्फ आमंत्रित करता है, "मुझे लगता है कि गिट बहुत जीत है, और svn तेह suxorz!" जवाब।

मैंने कोशिश की और व्यक्तिगत रूप से अपनी छोटी टीम के लिए Git को बहुत अधिक पाया। ऐसा लगता था कि यह बड़ी वितरित टीम या टीमों के समूह के लिए बहुत अच्छा होगा जो भौगोलिक रूप से बिखरे हुए हैं। मैं Git के लाभों को बहुत समझता हूं, लेकिन मेरी राय में स्रोत नियंत्रण कुछ ऐसा नहीं है जो मुझे रात में रखता है।

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

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

Comments

वास्तव में? फिर मैं आपको सुझाव दूंगा कि आप जीवाश्म को देखें ।

— स्पेंसर रथबुन

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

— डग

@SpencerRathbun, धन्यवाद! मुझे उस पर एक नजर डालनी होगी। यह इतना नहीं है कि मैं svn को प्यार करता हूं क्योंकि मेरे पास गिट के लिए एक अरुचि है।

— maple_shaft

@ स्पेंसर - दोनों के उपयोगकर्ता के रूप में, कॉन्ट्रैरीवाइज़ gitऔर hg, मुझे लगता है कि बहुत ज्यादा सोचने वाले किसी भी व्यक्ति के लिए मर्क्यूरियल सुझाएगा git। TortoiseHG TortoiseSVN (यह भी विंडोज पर एक ही एक्सप्लोरर ओवरले साझा करता है) के लिए इस्तेमाल किसी के लिए बहुत परिचित होगा । यह निश्चित रूप से वीएसएस की तुलना में बहुत आसान है और मुझे आश्चर्य होगा कि अगर यह एक एचजी रेपो स्थापित करने के लिए कुछ सेकंड से अधिक समय लेता है, तो प्रारंभिक स्थिति का वादा करता है और इसे एक साझा ड्राइव पर क्लोन करता है।

— मार्क बूथ

@MarkBooth मूल प्रश्न में कहा गया है, मुझे लगता है कि यह चाहता है और जरूरतों की बात है। मेरे वर्तमान कार्यस्थल पर, मेरे वहां पहुंचने से पहले कोई रेपो नहीं था। मुझे कुछ ऐसा चाहिए था, जो सभी के पास था या सबसे ज्यादा, जिस प्रोजेक्ट टूल को मैं एक साथ लपेटना चाहता था, उसका उपयोग करना आसान था, डेल्टास के बजाय सब कुछ रखा , और कई मशीनों में 1 या 2 लोगों की टीमों के लिए वितरित किया जाएगा।

— स्पेंसर रथबुन

Answer 8

यह सब सापेक्ष है, और जैसे मेपल_शाफ्ट ने कहा, अगर कोई आपके लिए काम करता है, तो मत बदलो!

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

Comments

एसवीएन उन्हें बेहतर तरीके से कैसे संभालता है? Git हर फाइल को BLOB मानता है।

— वारेनटी

@WarrenT क्योंकि वर्कफ़्लोज़ की वजह से, आप बहुत ब्रांच कर रहे हैं और मर्ज कर रहे हैं (या इसे इस्तेमाल करने से क्यों परेशान हैं) और आप बस बायनेरिज़ को मर्ज नहीं कर सकते। इसलिए, आप अक्सर एसवीएन में बाइनरी फ़ाइलों पर "जरूरतों को लॉक" संपत्ति डालते हैं।

— gbjbaanb

कुछ बायनेरिज़ (सैद्धांतिक रूप से) विलय किए जा सकते हैं, उदाहरण के लिए, एक ओडीटी दस्तावेज़।

— डोनल फैलो

Answer 9

प्रयोज्य। यह वास्तव में तोड़फोड़ की योग्यता नहीं है, बल्कि TortoiseSVN की है। TortoiseSit मौजूद है, लेकिन अभी भी TortoiseSVN से मेल खाने के लिए लंबा रास्ता तय करना है।

अगर आपने पूछा कि एसवीएन से बेहतर क्या है तो मैं GitHub का जवाब दूंगा । यह मजेदार है कि तीसरे पक्ष के उपकरण इतने बड़े अंतर को कैसे बनाते हैं।

Comments

असेंबला ( किसी भी समर्थित एससीएम - सूची में एसवीएन) गितुब से बेहतर है, मुझे लगता है

— आलसी बेजर

अब स्मार्टगिट, GitXL इत्यादि भी हैं, जो ऐसे कार्यक्रमों का उपयोग करते हैं जो git way को और अधिक सरल

— बनाते हैं

@LazyBadger, कभी इसके बारे में नहीं सुना।

— पचेरियर

Answer 10

जब आपको शाखा और विलय करने की आवश्यकता नहीं होती है , तो SVN ( विंडोज पर TortoiseSVN के साथ ) समझने और उपयोग करने में बहुत आसान है। सरल मामलों के लिए गिट अत्यधिक जटिल है, क्योंकि यह ब्रांचिंग / मर्जिंग को आसान बनाने की कोशिश करता है।

(बहुत सारी छोटी परियोजनाओं को कभी भी शाखा में नहीं रखना पड़ता अगर वे अच्छी तरह से प्रबंधित की जाती हैं। गिट जटिल मामलों के लिए लक्षित है; इसलिए अधिकांश गिट प्रलेखन आपको मानते हैं कि आपको ब्रांचिंग और विलय जैसे जटिल संचालन करने की आवश्यकता है।)

Comments

gitब्रांचिंग और मर्जिंग का उपयोग करना कोई जटिल ऑपरेशन नहीं है। मैं यहां तक ​​कि एक-एक परियोजना में शाखाओं का उपयोग करता हूं, तब भी जब कई संस्करण के लिए कोई आवश्यकता नहीं होती है। काम को जारी रखते हुए आप उस समय शाखा में नहीं रह सकते हैं, जब आपको पता चलता है कि एक और समाधान की कोशिश करना बेहतर हो सकता है ... हालाँकि, मैं मानता हूँ कि gitसीखना थोड़ा कठिन है।

— मेआर्टिनस

किसी भी समय आपको पुराने संस्करणों में बगफिक्स करने की आवश्यकता होती है जो आपको ब्रांचिंग और मर्जिंग की आवश्यकता होती है।

लोग इस विचार पर विचार क्यों नहीं करते हैं कि भांग svn या git से ज्यादा आसान है?

— वॉरेन पी

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

— इयान

Answer 11

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

अब यह वास्तव में मेरे दादाजी के लिए कोई मायने नहीं रखता, क्योंकि उन्होंने कोई प्रोग्रामिंग देर से नहीं की है। हालांकि, मैं एक बार एक टीम में था, जहां हमारे ग्राफिक कलाकार हमारे स्रोत नियंत्रण का उपयोग कर रहे थे।

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

Comments

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

— wirrbel

Answer 12

काम पर मैं दो कारणों से एसवीएन से डेवलपर्स को किसी डीवीसीएस में नहीं बदल सका :

• आंशिक चेकआउट (प्रोजेक्ट ट्री में अलग-अलग गहराई से केवल तीन फ़ोल्डर्स जैसे)
• फ़ाइल लॉकिंग (बाइनरी प्रारूप रिपोर्ट)

Answer 13

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

Comments

प्रमाणीकरण समस्या के लिए +1। Git कमिट पर हस्ताक्षर करने की आवश्यकता है, और साइनिंग को जांचना आवश्यक है जो कि मुश्किल है।

— क्रिश्चियन

Answer 14

अन्य लोगों ने कुछ बहुत अच्छे उत्तर पोस्ट किए हैं, लेकिन अनुमतियों के बारे में क्या? SSH के ऊपर तोड़फोड़ का उपयोग करके, आप SVN के लिए अपने सर्वर पर एक अलग खाता बना सकते हैं। विभिन्न डेवलपर्स को रिपॉजिटरी के विभिन्न हिस्सों में अलग-अलग एक्सेस दिया जा सकता है। क्या जीआईटी ऐसा कर सकता है? मुझे लगता है कि वहाँ gitolite है, लेकिन यह सिर्फ मुझे लचीला या मजबूत नहीं लगता है, और न ही मैं किसी को भी जानता हूं जो वास्तव में इसका उपयोग कर रहा है।

Comments

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

— al

प्रोजेक्ट लीड और लेफ्टिनेंट के धन्य भंडार पर नियंत्रण दिया जा रहा है कि कौन क्या कर सकता है। HTTP- सक्षम सक्षम सर्वर (एक ही अपाचे मॉड्यूल का उपयोग करते हुए svn करता है) पर प्रकाशित Git repo प्रमाणीकरण करते हैं और कहते हैं कि कौन क्लोन / चेकआउट कर सकता है। निश्चित रूप से, यह उतना नहीं है जितना कि svn प्रति निर्देशिका अनुमतियाँ हो सकती हैं, लेकिन मेरे लिए यह वास्तविक आवश्यकता से अधिक सूक्ष्म प्रबंधन जैसा दिखता है।

— ह्यूबर्ट करियो

@HubertKario - यह सवाल उठाता है, "क्या आपके सर्वश्रेष्ठ प्रोग्रामर अपना समय अन्य लोगों के कोड में चेक करने में बिता रहे होंगे?" वास्तव में, मुझे इस प्रश्न के उत्तर में इतनी दिलचस्पी है, कि मैंने इसे यहां पोस्ट किया है: प्रोग्रामर.स्टैकएक्सचेंज

— com

Answer 15

स्पीड। कभी-कभी एक बड़ी गिट रिपॉजिटरी को क्लोन करने में 10 या 15 मिनट लगते हैं, जबकि एक समान आकार के तोड़फोड़ रिपॉजिटरी को जांचने में कुछ मिनट लगते हैं।

Comments

लेकिन चेकआउट / क्लोनिंग एक दुर्लभ ऑपरेशन है। अधिकांश परिदृश्यों में, तोड़फोड़ की तुलना में गिट तेज होता है।

— आरडीएस

git clone --depth=1अगर आप इतिहास की परवाह नहीं करते तो आपका दोस्त है

— ह्यूबर्ट करियो

Answer 16

मैं इसे टिप्पणी के बजाय प्रतिक्रिया के रूप में पोस्ट करता हूं।

मैं मानता हूँ कि अभी DVCS काफी चलन में है, लेकिन मैं यह बताने की कोशिश करूँगा कि क्यों।

डीवीसीएस बेहतर हैं क्योंकि जैसे बहुत सारे लोग कह रहे हैं, "यह वह तरीका है जो हमें शुरुआत से काम करना चाहिए था"। यह सच है, आप एक DVCS के साथ कर सकते हैं जो आपने SVN के साथ उपयोग किया था, इसलिए एक तरह से जो SVN को अप्रचलित बनाता है।

हालाँकि, हर सॉफ्टवेयर प्रोजेक्ट उतना अच्छा नहीं है जितना कि यह मिलता है:

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

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

बाद के मामले के लिए, डेवलपर्स को वास्तव में ब्रांचिंग या परिष्कृत सुविधाओं की आवश्यकता नहीं होती है DVCS की पेशकश कर सकते हैं, वे सिर्फ स्रोत कोड और संपत्ति साझा करना चाहते हैं। उनके द्वारा बनाए गए कोड का पुन: उपयोग होने की संभावना नहीं है, क्योंकि एक समय सीमा है। वे कई कारणों की वजह से DVCS के बजाय SVN पर भरोसा करते हैं:

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

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

DVCS इंटरनेट के लिए और बहुत जटिल परियोजना के लिए बने हैं। एसवीएन छोटे, लघु अवधि, तंग टीम परियोजनाओं के लिए हैं। आपको SVN से बहुत कुछ सीखने की ज़रूरत नहीं है, यह लगभग एक एफ़टीपी है जो एक गूंगा अंतर है।

Comments

क्या आप खेल उद्योग का उदाहरण बता सकते हैं?

— जॉनी

Answer 17

तोड़फोड़ और गिट दोनों विकास और सहयोग के लिए विशेष (और बहुत अलग) दृष्टिकोण को प्रोत्साहित करते हैं। कुछ संगठन Git से अधिक बाहर निकलेंगे, और अन्य अपने संगठन और संस्कृति के आधार पर अधिक तोड़फोड़ से बाहर निकलेंगे।

Git और Mercurial दोनों अत्यधिक सक्षम पेशेवर प्रोग्रामर की वितरित और शिथिल संगठित टीमों के लिए उत्कृष्ट हैं। ये दोनों लोकप्रिय डीवीसीएस उपकरण छोटे रिपॉजिटरी को प्रोत्साहित करते हैं, डेवलपर्स के बीच पुन: उपयोग के साथ प्रकाशित पुस्तकालयों के माध्यम से (अपेक्षाकृत) स्थिर इंटरफेस के साथ होते हैं।

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

यदि आपकी टीम वितरित की जाती है, तो सदस्यों के साथ या तो घर से या कई अलग-अलग अंतरराष्ट्रीय साइटों से काम कर रहे हैं, या यदि वे अकेले और चुपचाप काम करना पसंद करते हैं, तो आमने-सामने संचार के साथ, फिर एक DVCS जैसे Git या Mercurial एक अच्छा होगा सांस्कृतिक फिट।

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

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

अंत में, मुझे यह भी पता चला है कि Svn (CI & a-test-approach) के तहत "हॉट" लाइब्रेरी डेवलपमेंट का उपयोग करते हुए कार्यक्षमता साझा करना समन्वित विकास की गति को अनुमति देता है जो कि अधिक वितरित और शिथिल-युग्मित टीम के साथ हासिल करना मुश्किल है।

Answer 18

नीचे दो कारण दिए गए हैं कि मैं अभी भी एसवीएन के साथ हूं।

1. सीखने की अवस्था। SVN Git, यहां तक ​​कि सेटअप (सर्वर या क्लाइंट), प्रयोज्य और कमांड से भी आसान है।
2. की तरह बेहतर सर्वर संकुल सबवर्सन एज , VisualSVN , uberSVN आदि

Comments

# 1 के लिए +1। एसवीएन बनाम जीआईटी आरेखों की तुलना यहाँ करें steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git

— s_t_e_v_e

Answer 19

अभी संस्करण नियंत्रण में दो प्रमुख रुझान हैं; वितरण, और एकीकरण ।

विकेंद्रीकरण में गिट महान है।

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

एसवीएन के साथ ऐसा करने वाले उपकरण परिपक्व होते हैं, और हर दिन उपयोग किया जाता है।

Answer 20

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

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

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

Comments

यह भी सीधा करने के लिए git में है; उदाहरण के लिए, git --amend; ऐसा करने का एक और तरीका git reset --soft HEAD ^ के माध्यम से है, जो अभी वापस चलता है, लेकिन इंडेक्स में बदलाव नहीं करता है, और इसलिए आप कमिट मैसेज को एडिट / री-राइट कर सकते हैं।

— डग

हाय, डग। हां, आप इसे अपने स्थानीय रिपॉजिटरी के लिए कर सकते हैं, लेकिन मैं एक बार आपके द्वारा बदलाव को कहीं और धकेलने के बारे में बात कर रहा हूं - "git प्रतिबद्ध --amend" तब आपकी बहुत मदद नहीं करता है। एसवीएन में, आप केंद्रीय सर्वर पर लॉग संदेश को संपादित कर सकते हैं, ठीक है क्योंकि केंद्रीय सर्वर की अवधारणा है। यही मेरा मतलब है "विकेंद्रीकृत प्रणालियों में डिजाइन द्वारा असंभव"। मैं इसे स्पष्ट करने के लिए अपने उत्तर को संपादित करूँगा।

— कार्ल फोगेल

मैं प्यार करता हूँ कि "आप इतिहास के साथ कैसे फील कर सकते हैं" कथित तौर पर एक विशेषता है । अगर यह जानबूझकर नहीं होता तो मैं इसे एक बग मानता हूं।

— cHao