क्या एक ही svn भंडार के विभिन्न गिट-एसवीएन क्लोन परिवर्तनों को साझा करने में सक्षम होने की उम्मीद कर सकते हैं तो svn dcommit git?




git-svn code-sharing (5)

एक उपकरण है जो सबवर्सन रिपोजिटरी के साथ सिंक्रनाइज़ किए गए गिट रिपॉजिटरी को साझा करने की समस्या को हल करता है।

सबगिट एक गिट-एसवीएन द्वि-दिशात्मक सर्वर-साइड दर्पण है।

कोई सबगिट सबवर्सन रिपॉजिटरी में स्थापित कर सकता है और गिट रिपोजिटरी स्वचालित रूप से एसवीएन के साथ सिंक्रनाइज़ हो सकता है:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

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

सबगिट गिट-एसवीएन पर भरोसा नहीं करता है, यह हमारे स्वयं के अनुवाद इंजन का उपयोग करता है हमारी टीम विकसित हुई है। इस पर अधिक जानकारी आप SubGit बनाम git-svn तुलना में पा सकते हैं। सबगिट पर सामान्य दस्तावेज here उपलब्ध here

सबगिट के संस्करण 1.0 में सबवर्सन रिपोजिटरी के लिए स्थानीय पहुंच की आवश्यकता है, यानी एसवीएन और गिट रिपॉजिटरीज़ को उसी होस्ट पर रहना होगा। लेकिन संस्करण 2.0 के साथ हम गिट प्रॉक्सी मोड पेश करने जा रहे हैं, जब सबवर्सन और गिट रिपॉजिटरीज कहीं भी स्थित हो सकते हैं और केवल गिट रिपॉजिटरीज में सबगिट स्थापित है, यानी सबवर्सन रिपोजिटरीज बिना छूटे रहते हैं।

सबगिट एक वाणिज्यिक उत्पाद है। यह ओपन-सोर्स, अकादमिक परियोजना और 10 कमिटर्स वाली परियोजनाओं के लिए भी नि: शुल्क है।

अस्वीकरण: मैं सबगिट डेवलपर्स में से एक हूं।

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

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

मैंने जो पढ़ा है उसके आधार पर, मुझे लगता है कि समस्याएं हो सकती हैं जब उस विशिष्ट तरीके से गिट-एसवीएन का उपयोग किया जाता है, जिसे मैं नीचे वर्णित करूंगा। क्या कोई मुझे बता सकता है कि मैं इसके बारे में सही हूं?

चीजों को करने का "वांछित" तरीका यहां दिया गया है:

  1. हमारे पास एक svn भंडार में एक परियोजना है
  2. डेवलपर ए गिट-एसवीएन-क्लोन एसवीएन रेपो। वह स्थानीय रूप से चीजों को हैक करना शुरू कर देता है
  3. डेवलपर बी गिट-एसवीएन-क्लोन एक ही svn repo है। वह अपने आप चीजों को हैक करना शुरू कर देता है।
  4. कुछ समय के लिए ऐसा करने के बाद, संभवतः देवता सी / डी / ... जोड़ना, और अन्य डेवलपर्स जो "मानक" svn करते हैं, मूल रेपो में काम करते हैं, गिट उपयोगकर्ता अपने कोड को साझा करना चाहते हैं और सभी प्रकार के गिट जादू करना चाहते हैं ।
  5. उन गिट प्रयोक्ताओं में से कोई भी अब विलय किए गए परिवर्तनों को svn (dcommit?) में धक्का दे सकता है

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

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

क्या मैं पूरी तरह से गिट-एसवीएन चेतावनी को गलत समझ रहा हूं? क्या ऐसा करने का कोई आसान तरीका है?


गिट-एसवीएन के साथ मुझे लगता है कि समस्याओं में से एक यह है कि यह प्रतिबद्ध टिप्पणी में गिट-एसवीएन-आईडी स्टोर करता है; क्योंकि यह प्रतिबद्धता को फिर से लिखता है, यह इसके SHA1 को बदलता है, ताकि आप कहीं भी इसे साझा नहीं कर सकें, लोग इसे साझा करेंगे।

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


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


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

यह सही ढंग से काम करना प्रतीत होता था क्योंकि हम गिट उपयोगकर्ताओं के बीच "विशिष्ट गिट फीचर्स" का उपयोग करने में सक्षम थे, जब तक हम एक रैखिक पेड़ (यानी विलय के बजाए रिबेसिंग) में रहे।


समस्या निश्चित रूप से चरण 4 है। एक डॉकिटिट आपके स्थानीय इतिहास को सर्वर पर फिर से चलाने की कोशिश करता है। डॉकिट ने दिखाया कि आप एक एसवीएन ग्राहक हैं। अब, यदि आप जिस कोड को कम कर रहे हैं वह न केवल आपके द्वारा है, यह ऐसा कुछ है जो एसवीएन को कम करना मुश्किल है।

इस मामले पर guru क्या लिखते हैं:

  • सादगी के लिए और एसवीएन के साथ अंतःक्रिया करने के लिए, यह अनुशंसा की जाती है कि सभी गिट-एसवीएन उपयोगकर्ता सीधे एसवीएन सर्वर (रिमोट एसवीएन रिपोजिटरी) से क्लोन, लांच और डॉकिट करें, और सभी गिट-क्लोन / पुल / मर्ज / पुश से बचें गिट रिपॉजिटरीज और शाखाओं के बीच संचालन जिन्हें गिट एसवीएन क्लोन के माध्यम से या तो पुनर्प्राप्त किया जाता है और जिन्हें रिमोट एसवीएन रिपोजिटरी में बदलावों को वापस धक्का देने के लिए भी उपयोग किया जाता है।
  • गिट शाखाओं और उपयोगकर्ताओं के बीच कोड का आदान-प्रदान करने की अनुशंसित विधि गिट प्रारूप-पैच और गिट एम है, या सिर्फ एसवीएन भंडार के लिए svn dcomit gitit है।
  • चूंकि गीट svn dcommit आंतरिक रूप से गिट svn rebase का उपयोग करता है, किसी भी गिट शाखाओं को हम गिट svn dcommit से पहले धक्का देते हैं, उन्हें रिमोट रिपोजिटरी पर मौजूदा रेफरी के ओवरराइट को मजबूर करने की आवश्यकता होगी। इसे आम तौर पर खराब अभ्यास माना जाता है, विवरण के लिए गिट-पुश दस्तावेज़ीकरण देखें।
  • एक शाखा पर गिट मर्ज या गिट पुल चलाने की अनुशंसा नहीं की जाती है जिसे हम svn dcommit से गिट करने की योजना बनाते हैं। एसवीएन किसी भी उचित या उपयोगी फैशन में विलय का प्रतिनिधित्व नहीं करता है, इसलिए एसवीएन का उपयोग करने वाले उपयोगकर्ता हमारे द्वारा किए गए किसी भी विलय को नहीं देख सकते हैं। इसके अलावा, अगर हम एक गिट शाखा से विलय या गिट खींचते हैं जो एक एसवीएन शाखा का दर्पण है, तो गिट svn dcommit गलत शाखा में प्रतिबद्ध हो सकता है।
  • गिट क्लोन रेफरी / रिमोट / पदानुक्रम या किसी भी गिट-एसवीएन मेटाडाटा, या कॉन्फ़िगरेशन के तहत शाखाओं को क्लोन नहीं करता है। तो गिट-एसवीएन का उपयोग करने के साथ बनाए गए और प्रबंधित भंडारों को क्लोनिंग के लिए rsync उपयोग करना चाहिए, अगर क्लोनिंग पूरी तरह से की जानी चाहिए।
  • हमें उस बदलाव पर गिट प्रतिबद्धता के --एंडेंड विकल्प का उपयोग नहीं करना चाहिए जिसे हम पहले से ही कम कर चुके हैं। इसे कम करने के लिए बुरी आदत माना जाता है - हम पहले से ही अन्य उपयोगकर्ताओं के लिए रिमोट रिपोजिटरी में धकेल चुके हैं, और एसवीएन के साथ डॉकिटिट इसके समान है। इस पर अधिक जानकारी एक ही प्रतिबद्धता और पुनर्लेखन इतिहास के साथ समस्याओं को संशोधित करने में मिल सकती है।







code-sharing