पूर्व-प्रतिबद्ध स्क्रिप्ट के भीतर, क्या यह संभव है (और यदि हां, तो कैसे) svn merge से उत्पन्न कमिट्स की पहचान करना?

svnlook changed ... उन फ़ाइलों को दिखाता है जो बदल गई हैं, लेकिन मर्ज और मैन्युअल संपादन के बीच अंतर नहीं करती हैं।

आदर्श रूप से, मैं एक मानक merge और एक merge --reintegrate के बीच अंतर करना चाहूंगा।

पृष्ठभूमि:

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

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

कोई विचार?


अद्यतन:

मैंने svnlook कमांड की खोज की है, और मेरे पास सबसे नज़दीकी है निर्देशिका की svn:mergeinfo संपत्ति में परिवर्तनों का पता लगाना और उनका विश्लेषण करना। इस दृष्टिकोण में कुछ कमी है:

  1. svnlook गुणों में बदलाव को चिह्नित कर सकता है, लेकिन यह नहीं कि कौन सी संपत्ति बदली गई थी। (पिछले संशोधन के proplist के साथ एक अंतर आवश्यक है)
  2. svn:mergeinfo में परिवर्तनों का निरीक्षण करके, यह पता लगाना संभव है कि svn merge चलाया गया था। हालांकि, यह निर्धारित करने का कोई तरीका नहीं है कि क्या कमिट पूरी तरह से मर्ज का परिणाम है। मर्ज के बाद मैन्युअल रूप से किए गए परिवर्तन ज्ञात नहीं होंगे। (संबंधित पोस्ट: डिफ ट्रांजैक्शन ट्री अगेंस्ट अदर पाथ/रिविजन)
12
Shawn Chin 9 जिंदा 2012, 19:17
क्या आपको पुनर्एकीकरण और नियमित विलय के बीच अंतर करने की आवश्यकता है?
 – 
Álvaro González
9 जिंदा 2012, 19:24
@ÁlvaroG.Vicario आदर्श रूप से, हाँ। लेकिन मैं बस किसी भी प्रकार के विलय का पता लगाने के लिए तैयार हूं।
 – 
Shawn Chin
9 जिंदा 2012, 19:33
मुझे नहीं लगता कि svn:mergeinfo को पार्स करना नाजुक है: वह संपत्ति सबवर्सन द्वारा परिवर्तनों को ट्रैक करने के लिए उपयोग की जाने वाली तंत्र है। हालांकि, मुझे यकीन नहीं है कि --reintegration विकल्प का संशोधन गुणों पर कोई सीधा प्रभाव पड़ता है। क्षमा करें मैं और अधिक सहायता नहीं कर सकता।
 – 
Álvaro González
9 जिंदा 2012, 19:47
@ÁlvaroG.Vicario अच्छी बात है। मैं इसमें आगे देखूंगा।
 – 
Shawn Chin
9 जिंदा 2012, 20:11
दुर्भाग्य से, केवल svn:mergeinfo को देखना ही काफी नहीं है। ऊपर अपडेट देखें।
 – 
Shawn Chin
11 जिंदा 2012, 16:05

2 जवाब

सबसे बढ़िया उत्तर

मैंने अंततः एक गैर-आदर्श समाधान का सहारा लिया है, यानी परिवर्तन ट्री की शीर्ष निर्देशिका में svn:mergeinfo संपत्ति में परिवर्तन का पता लगाना (SVNTransaction.is_merge_operation())।

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

यह merge और merge --reintegrate के बीच अंतर नहीं कर सकता।

अन्य सीमाओं में svn:mergeinfo पर निर्भरता शामिल है जो उपयोगकर्ता-परिवर्तनीय है और तोड़फोड़ के पुराने संस्करण में उपयोग नहीं की जाती है।

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

2
Community 23 मई 2017, 15:04

दुर्भाग्य से तोड़फोड़ केवल मर्ज को लागू नहीं करता है

अगर मेरे पास किसी शाखा तक पहुंच है, तो मैं विलय के बाद और प्रतिबद्ध होने से पहले जो कुछ भी कर सकता हूं

ग्राहक पक्ष पर भी तोड़फोड़ विलय होता है

बहुत सारे कोड रिपॉजिटरी टूल सर्वर पर मर्ज हो जाएंगे। यानी लागू करें कि आप केवल पैच को एक स्ट्रीम से दूसरी स्ट्रीम में ले जा रहे हैं

2
Kalpesh Soni 4 मई 2012, 20:29