संघर्ष सबवर्सन

Question

में परिवर्तन पूर्ववत किए उदाहरण के प्रयास में जब सबवर्सन में कार्यक्षमता में, मैं उपयोग के मामले परिवर्तन पूर्ववत किए शाखाओं में बंटी की बुनियादी विलय खंड के उपधारा और svnbook के विलय अध्याय में वर्णित परीक्षण करने के लिए प्रयास किया। मैं संस्करण 1.6.4 का उपयोग कर रहा हूं, लेकिन उस खंड के लिए पाठ पुस्तक के दोनों संस्करणों में समान है।

मेरी कार्यशील प्रति निर्देशिका में, मैं एक फ़ाइल testcode.py संपादित करता हूं, प्रति संपादन एक पंक्ति जोड़ता हूं, और प्रत्येक संपादन के बाद करता हूं। कई प्रतिबद्ध करने के बाद, इस प्रकार फ़ाइल में लिखा है:

this is my first import to trunk. r1. 

this is my first commit, first edit of testcode.py. r2. 

this is another edit of testcode.py. r3. 

this is an edit of testcode.py. i'll get rid of this one. r4. 

this is another edit of testcode.py. keeping it. r5. 

yet another edit. keeping it. r6. 

भंडार मैच में संशोधन संख्या फ़ाइल में लाइनों को इस तरह के /trunk/testcode.py@rN में, फ़ाइल की अंतिम पंक्ति है कि आरएन के साथ समाप्त एक। मैं जो करना चाहता हूं वह आर 4 में समाप्त होने वाली रेखा को हटा देता है, अपरिवर्तित से पहले और बाद में सबकुछ रखता है।

svnbook के परिवर्तन पूर्ववत किए खंड में उदाहरण के बाद, मैं आदेश

svn merge -c -4 file:///path_to_repos/trunk 

यह एक संघर्ष, (जो आदेश चलाकर, पर नहीं करने पर) बनाता है चलाने जिससे मर्ज-बाएँ फ़ाइल सब कुछ होता है लाइन आर 4 तक, और मर्ज-दाएं फ़ाइल में लाइन आर 3 तक सब कुछ शामिल है। दूसरे शब्दों में, पिछले परिवर्तन को हटाने के बजाय, कमांड पूरी फ़ाइल को या तो संशोधन 3 या 4 पर वापस लेना चाहती है, बाद में संशोधन (5 और 6, इस मामले में) में परिवर्तनों को हटा रही है।

जिस तरह से मैंने svnbook में उदाहरण पढ़ा है, जिसने उपयोगकर्ता को 303 में किए गए बदलाव को उलट दिया है और परिणाम को बिना किसी विरोध के 350 के संशोधन के लिए परिणाम दे रहा है, मेरे द्वारा चलाए गए आदेश को एक एसवीएन स्थिति के साथ एक फाइल बनाई जानी चाहिए एम जो आर 4 में समाप्त होने के अलावा सभी लाइनों को बरकरार रखता है।

क्या मैं पुस्तक के उदाहरण को गलत तरीके से पढ़ रहा हूं, क्या उदाहरण गलत है, या क्या उपयोगकर्ता त्रुटि का कोई अन्य रूप है, मैं अनजान में गिर गया?

Answer 1

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

later commit (r5) 
change to be reverted at beginning of file (r2) 
initial commit (r1) 
change to be reverted in middle of file (r3) 
initial commit (r1) 
change to be reverted at end of file (r4) 
later commit (r5) 

(संशोधन 2 और 4 उदाहरण में) फ़ाइल के आरंभ या अंत करने के लिए प्रतिबद्ध वापस लौटने की कोशिश कर रहा है, एक संघर्ष देता है। परिवर्तन के रूप में फ़ाइल के बीच में परिवर्तन को वापस करने के रूप में काम करता है।

वैचारिक रूप से, यह एक गुंजाइश आसपास लाइनों द्वारा सीमित होने के रूप में changesets के बारे में सोच करने के लिए मदद कर सकते हैं। फ़ाइल के बीच में परिवर्तन आसपास के अपरिवर्तित रेखाओं से घिरा हुआ है। शुरुआत या एक फ़ाइल के अंत में एक परिवर्तन की गुंजाइश कितनी दूर दूर उस जगह बाद में ले जाया जाता है की परवाह किए बिना शुरुआत या फ़ाइल के अंत तक सभी तरह फैली हुई है।

इसलिए उपरोक्त उदाहरण में, दूसरी पंक्ति संशोधन 5 में जोड़ा सही संशोधन 4 की गुंजाइश के बीच में आता है।

...     <-- Line unchanged by revision 10, bounding its scope 
line from revision 10 <--\ 
line from revision 11  | Revision 10's scope 
line from revision 10 <--/ 
...     <-- Line unchanged by revision 10, bounding its scope 

आप एक संघर्ष यहाँ की उम्मीद करनी चाहिए, एक ही कारण के लिए:

उसी तरह है कि आप यहाँ संशोधन 10 को वापस लाने में एक संघर्ष उम्मीद थी क्योंकि संशोधन 11 में परिवर्तन इसे के बीच में स्मैक थपका हैं

...     <-- Line unchanged by revision 10, bounding its scope 
line from revision 10 <--\ 
line from revision 11  | Revision 10's scope 
<EOF>     <--/ (No unchanged line bounding the scope this direction) 

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