1. घर
  2. सवाल और जवाब
  3. `hg pull --rebase` 'svn update` के समान है?

`hg pull --rebase` 'svn update` के समान है?

2010-03-01 12 views
22

यह सवाल वहाँ एक "धन्य" केंद्रीय भंडार है कि एक टीम के सदस्यों`hg pull --rebase` 'svn update` के समान है?

  1. वे योगदान है कि वे चाहते हैं जब करने के लिए
  2. धक्का से क्लोन टीम के अन्य सदस्यों से जब वे चाहते हैं
  3. पुल को देखने के लिए है मान लिया गया है अन्य लोगों के योगदान देखने के लिए।
  4. आदि

यदि हां, तो मैं hg update ग्रहण करेंगे (क्यों वहाँ दो आदेशों को बिल्कुल वही बात करना हो सकता है?) svn update के अनुरूप नहीं है। मैं जो इकट्ठा कर सकता हूं, hg updatesvn revert की तरह। क्या वो सही है?

अद्यतन:

रिबेस के मेरे समझ बड़े पैमाने इस पृष्ठ पर "एक आम मामले" खंड पर आधारित है:
https://www.mercurial-scm.org/wiki/RebaseProject

स्रोत

2010-03-01 allyourcode

उत्तर

41

जैसा कि अन्य ने संकेत दिया है, लगभग लेकिन काफी नहीं। svn update को समानता को कम करने के लिए आदेश में (और सामान्य DVCS के अनुपालन में वृद्धि, और विशेष रूप मर्क्युरियल, सर्वोत्तम प्रथाओं [1]):

  1. hg pull -u (या hg pullhg update के बाद) अपने परिवर्तन अप्रतिबद्ध और के बाद से कोई प्रतिबद्ध परिवर्तन के साथ आपका आखिरी पुल यह svn update के करीब है जैसा कि आप प्राप्त कर सकते हैं, लेकिन DVCS अभ्यास बहुत खराब है। डीवीसीएस की नस्लों में से एक यह है कि आप दूसरों के साथ विलय करने की कोशिश करने से पहले अपने परिवर्तन कर सकते हैं, और इस प्रकार रोलबैक के लिए बैकअप संस्करण है और एक असफल विलय पुनः प्रयास करें, और यह अभ्यास इसे देता है। ऐसा मत करो

  2. hg pull --rebase आपके परिवर्तन करने के बाद। यह अपस्ट्रीम परिवर्तनों को खींचता है, उनके शीर्ष पर आपके परिवर्तनों को फिर से लागू करता है, और आपको अपने परिवर्तनों को रैखिक इतिहास के रूप में वापस करने देता है।अंतिम परिणाम सबवर्सन संशोधन इतिहास के समान ही दिखाई देगा, लेकिन आपको विलय करने से पहले DVCS लाभ प्राप्त करने का लाभ मिलता है। मुझे नहीं पता कि ऑपरेशन के इस तरीके की सुरक्षा कैसे Mercurial और Git के बीच तुलना करता है; गिट में, आपके परिवर्तनों के प्री-रीबेस संस्करण तब भी होंगे जब तक कि आप git gc नहीं करते हैं, लेकिन Mercurial के पास कोई स्पष्ट gc सुरक्षा नेट नहीं है।

  3. hg pullhg merge इसके बाद आपके स्थानीय प्रतिलिपि में पहले से ही आपके परिवर्तन किए गए हैं। svn update के कार्यात्मक एनालॉग को करने के लिए यह पारंपरिक मर्क्यूरियल अभ्यास है, नीचे दिए गए फुटनोट 1 के बावजूद। इसका परिणाम नॉनलाइनर संस्करण इतिहास में होता है, लेकिन सभी परिवर्तन ट्रैक और निरीक्षण योग्य होते हैं।

यानी, अपने स्वयं के शर्तों पर मर्क्युरियल (और अन्य DVCSes) के बारे में सोच में ज्यादा ज्ञान, और सबवर्सन/सीवीएस शैली सोच से अनुवाद की कोशिश नहीं है।

  1. यदि आप फिर से लिखने वाले इतिहास के विचार-विद्यालय-विचार-विद्यालय के विचार नहीं हैं। यदि आप हैं, तो rebase शायद update के लिए बेहतर है। Mercurial समुदाय update का पक्ष लेता है।

स्रोत

2010-03-21 15:25:06

+4

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

+0

एक अनुवर्ती प्रश्न यह था कि मैं यह था: ऐसा लगता है जैसे एचजी अपडेट केवल उपयोगी होगा यदि आपने कभी भी कोई काम नहीं किया है (जैसा कि 1 में है), क्योंकि उसके बाद, आप एक शाखा से काम कर रहे होंगे कि कोई भी और इसके बारे में जानता है। दोबारा, यह एक कार्य प्रवाह मानता है जिसमें एक धन्य केंद्रीय रेपो शामिल है जो एक टीम के सदस्य धक्का देते हैं और खींचते हैं। – allyourcode

+1

@allyourcode यदि आपके पास स्थानीय परिवर्तन हैं, तो, आपको अपडेट के बजाय विलय की आवश्यकता है। हालांकि, अद्यतन यह भी है कि आप संशोधन या नामित शाखाओं को कैसे स्विच करते हैं, और आपके परिवर्तनों को ऊपर की ओर धकेलने के बाद उपयोगी होता है। यदि आपको विलय करने और अद्यतन करने का प्रयास करने की आवश्यकता है, तो अपडेट विफल हो जाएगा, इसलिए मैं आमतौर पर पहले अद्यतन का उपयोग करता हूं और विफल होने पर विलय करता हूं। –

11

नहीं वास्तव में।

hg pull अन्य रिपोजिटरी से संशोधन पकड़ लेता है और उन्हें भंडार के अपने क्लोन में स्थानीय स्तर पर उपलब्ध संशोधन करने के लिए कहते हैं, लेकिन अपने काम की नकल अद्यतन नहीं करता है - केवल अपने भंडार (जो, एचजी की तरह DCVS के लिए/गिट/आदि एक कामकाजी प्रति के समान नहीं है)।

hg update आपकी वास्तविक कार्य प्रतिलिपि को आपके स्थानीय भंडार में नवीनतम संशोधन में अपडेट करता है।

यह सबवर्जन से अलग है क्योंकि svn में, आपके "स्थानीय भंडार" जैसी कोई चीज़ नहीं है - सर्वर पर एकमात्र भंडार है; आपके पास स्थानीय रूप से एक कार्यशील प्रतिलिपि है। इसलिए update केवल एक ही कमांड है, क्योंकि Mercurial के pull और उसके बाद update का विरोध किया गया है।

मर्क्युरियल के लिए svn update के बराबर hg pull --update, जो hg pull और फिर hg update एक के बाद एक कर के बराबर है किया जाएगा।

एक "केंद्रीय" रेपो साथ DCVS के लिए एक अंत से अंत कार्यप्रवाह इस तरह दिखता है:

  1. एक कुछ परिवर्तन पर hg commit करता है।
  2. ए hg push उन्हें केंद्रीय भंडार को धक्का देने के लिए करता है।
  3. बी hg pull केंद्रीय भंडार से अपने स्वयं के क्लोन में खींचने के लिए करता है।
  4. बी hg update उनके कामकाजी प्रति को अपने क्लोन में किए गए परिवर्तनों को दर्शाने के लिए अद्यतन करने के लिए करता है।

एक केंद्रीय रेपो बिना सिस्टम में, यह बजाय कुछ इस तरह दिखेगा:

  1. एक कुछ परिवर्तन पर hg commit करता है।
  2. बी, जिन्होंने ए के रेपो को क्लोन किया है, उन परिवर्तनों को चाहता है, और इस तरह ए 0 रेपो से सीधे hg pull करता है।
  3. बी hg update का उपयोग अपनी कार्य प्रतिलिपि को परिवर्तनों में अपडेट करने के लिए करता है।

इसके अलावा, svn revert के बराबर hg revert है। :)

स्रोत

2010-03-01 08:22:00 Amber

+1

मुझे पता है कि एचजी पुल - क्रेबेस एचजी पुल के बराबर एचजी पुल के बराबर है। रिबेस क्या करता है? अगर मैं एक ऐसी शाखा में काम करता हूं जो एचजी पुल नीचे खींच रहा है, तो क्या होगा - अपडेट काम करेगा? ऐसा लगता है कि रिबेज क्या है, यही कारण है कि मैं एचजी पुल - रीबेस को एसवीएन अपडेट के समान होने के बारे में सोचता हूं: यह केंद्रीय रेपो से बदलाव लेता है, उन्हें मेरी कामकाजी प्रतिलिपि में विलीन करता है, और मेरी कामकाजी प्रतिलिपि के माता-पिता को बदलता है (प्रतिबद्धताओं को प्रतिबद्ध करने से पहले हल करने की आवश्यकता हो सकती है)। – allyourcode

+3

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

+0

मैं जो बात कर रहा हूं उसके बारे में एक ग्राफिकल प्रतिनिधित्व http://mercurial.selenic.com/wiki/RebaseProject पर "एक आम मामला" शीर्षक के तहत देखा जा सकता है। – Amber

2 
hg pull --update

svn update

के समतुल्य अपने काम की नकल के बीच इस SO question

एचजी आदेश में वर्णित खजाने और update और commit चाल परिवर्तन के बीच push और pull कदम परिवर्तन के रूप में किया जाएगा और आपके स्थानीय भंडार।

एक DVCS में

तो, आप के बजाय 2 विचार एक है:

  • स्थानीय रेपो (पुल/धक्का)
  • कार्यशील निर्देशिका (जिनमें से "टिप" का केवल स्थानीय प्रतिनिधित्व है एसवीएन के साथ एक रेपो)

स्रोत

2010-03-01 08:22:31 VonC

+1

क्या एचजी पुल - अपडेट हैंडल करता है जब मैंने एक ऐसी शाखा में काम किया है जो रिमोट रेपो में काम करता है जिसे मैं एचजी पुल के साथ खींच रहा हूं? डेव को मेरी टिप्पणी में अधिक जानकारी। – allyourcode

2

यहां Mercurial http://hginit.com/ के लिए एक महान शुरुआती मार्गदर्शिका है। ज्यादातर चीजों को स्पष्ट रूप से समझा जाना चाहिए। "वितरित वीसीएस के लिए svn ज्ञान को आजमाएं और लागू न करें" से शुरू करना!

स्रोत

2010-03-01 08:29:02 Decado

+0

यह उत्तर मेरे विशिष्ट प्रश्न का उत्तर नहीं देता है। यहां तक ​​कि यदि प्रत्येक एचजी कमांड में एक svn एनालॉग नहीं होना चाहिए, तो भी आप अभी भी समझा सकते हैं कि hg pull --rebase और hg अद्यतन किस बारे में हैं। – allyourcode

+0

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

+2

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

2

कमांड hg pull --rebase बिल्कुल समान से svn update पर नहीं है, लेकिन परिणाम समान हो सकता है।

सबवर्सन में, यदि आप अपनी कार्यशील प्रति अपडेट करते हैं तो आपको किसी भी स्थानीय परिवर्तन के साथ विलय में भंडार में नवीनतम परिवर्तन मिलते हैं। तो आपके भंडार में फाइलें अद्यतित हैं लेकिन आपके पास अभी भी असामान्य परिवर्तन हो सकते हैं।

Mercurial, hg pull --rebase में, आपके भंडार को अद्यतन करने के लिए 'केंद्रीय भंडार' (या जो भी भंडार आप खींच रहे हैं) से नवीनतम परिवर्तन प्राप्त करेंगे, फिर अपने स्थानीय कामों के साथ घूमते हैं। अपनी कार्य प्रतिलिपि को अपने स्थानीय भंडार के समान बनाने के लिए आपको अभी भी hg update की आवश्यकता होगी।

स्रोत

2010-03-01 12:16:17

+0

धन्यवाद, निक। आपने जो कुछ कहा वह मुझे समझ में आता है। एकमात्र हिस्सा जो मैंने वास्तव में नहीं किया था वह आपकी आखिरी वाक्य थी। मान लीजिए कि आप इस पृष्ठ पर "एक आम मामला" खंड में दूसरे आरेख में चित्रित स्थिति में हैं: http://mercurial.selenic.com/wiki/RebaseProject। उस समय, आपकी कामकाजी प्रतिलिपि के माता-पिता एल 2 हैं। क्या आप कह रहे हैं कि एचजी रीबेस करने के बाद भी मेरी कामकाजी प्रतिलिपि का माता-पिता एल 2 होगा? क्या आप कह रहे हैं कि मुझे एचजी अपडेट करने की ज़रूरत है) आर 1 और आर 2 में मेरी कामकाजी प्रतिलिपि में बदलाव मर्ज करें, और बी) मेरी कामकाजी प्रतिलिपि के एल 2 'को बनाओ? – allyourcode

+0

मैं बस इतना कह रहा हूं कि आपकी कार्यशील प्रति और आपके स्थानीय भंडार के बीच एक अंतर है। खींचने के बाद "स्थानीय भंडार" (छिपी हुई .hg निर्देशिका में सबकुछ) अद्यतन किया गया है लेकिन आपकी कार्यशील प्रति (वास्तविक फाइल जिनके साथ आप काम कर रहे हैं) अप्रभावित है। अंतिम "अपडेट" आपके स्थानीय भंडार को प्रतिबिंबित करने के लिए आपकी कार्यशील प्रति को बदल देगा। –

+0

ध्यान दें कि "रीबेस" आपके स्थानीय भंडार में किए गए परिवर्तनों पर काम कर रहा है - यह आपकी कार्यशील प्रतिलिपि में असामान्य फ़ाइलों पर काम नहीं कर रहा है (जो svn से अलग है जिसमें स्थानीय भंडार नहीं है)। –

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

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