गिट और एसवीएन रेपोज़ के बीच ब्रिज के रूप में गिट का उपयोग करना?

Question

समस्या

मेरी टीम bitbucket पर स्रोत नियंत्रण के लिए Git का उपयोग करता है, हमारे ग्राहक के घर में सबवर्सन उपयोग करता है। सबवर्सन में कोड चेक करते समय हमारी टीम गिट का उपयोग कैसे जारी रख सकती है? और, नहीं, मुझे नहीं लगता कि गिट-एसवीएन काम करेगा।

आवश्यकताओं

मेरी टीम एक शुद्ध Git समाधान, नहीं Git-SVN का उपयोग करना चाहता है। इसका कारण यह है कि हमारे ग्राहक ने हमें अपने कार्यालय लैन के भीतर ही अपने एसवीएन पर्यावरण तक पहुंच प्रदान की है; हम कार्यालय से बाहर काम करते समय svn करने के लिए प्रतिबद्ध नहीं कर सकते हैं।

मेरे दृष्टिकोण

मैंने सोचा था कि मैं Git-svn का उपयोग कर तोड़फोड़ भंडार चेकआउट सकता है, तो एक ही Git स्वरुप में SVN भंडार के लिए एक रिमोट के रूप में हमारे bitbucket Git उदाहरण जोड़ें। एक क्रॉन जॉब हमारे बिटकबकेट रेपो से git pull कर सकता है, फिर बिगबकेट में हमारे क्लाइंट के सबवर्जन रिपोजिटरी में परिवर्तन को धक्का देने के लिए git svn dcommit करें।

यह कारण था कि गिट हमेशा दिखाएगा कि मैं पुल के बाद गिट बिटबकेट रिपोजिटरी से पहले संशोधनों की 'x' संख्या था, svn dcommit प्रक्रिया समाप्त हो गई।

जबकि कुछ भी बाहरी रूप से अजीब नहीं चल रहा है, कुछ बिंदु पर मुझे विश्वास है कि हमारा ग्राहक अपने उपवर्तन भंडार में चेक-इन बनाना शुरू कर देगा कि मुझे अंततः हमारे बिटबकेट उदाहरण को धक्का देना होगा।

तकनीकी विवरण

ये कदम उठाएँ मैं इस काम के प्राप्त करने की कोशिश करने के लिए उपयोग कर रहे हैं का एक मोटा श्रृंखला है: के बाद

git svn clone -s http://svn.my-client.us/my-proj/ 
cd my-proj 
git remote add origin path-to-bitbucket-repo 
git fetch origin 
git checkout -b develop remotes/develop 
git branch --set-upstream develop origin/develop 
git pull 
#add merge comment here 
git svn rebase 
git svn dcommit #takes a while to transfer all the individual commits 

सब से ऊपर, को क्रियान्वित करने git status:

[me@dev myDir]$ git st 
# On branch develop 
# Your branch is ahead of 'origin/develop' by 59 commits. 
# 
nothing to commit (working directory clean) 

यह देखते हुए कि मुझे किसी भी स्थान से चेक-इन करने में सक्षम होना चाहिए, न कि जब मैं कार्यालय में हूं, तो क्या कोई है ऐसा करने के लिए पुल के रूप में इसका उपयोग करने के लिए रणनीति?

धन्यवाद!

Answer 1

आपका दृष्टिकोण सही है, लेकिन आपको यह पता होना चाहिए कि dcommit सामान्य rebase से अधिक इतिहास को फिर से लिखता है। उदाहरण के लिए यह प्रत्येक प्रतिबद्धता के लिए git-svn-id लाइन जोड़ता है जो svn के लिए डॉक्यूटेड है। यही कारण है कि develop शाखा origin/develop से पहले दिखाई देती है - क्योंकि इसमें 59 में सभी git-svn-id संदेश हैं, और इनमें से कोई भी origin/develop में मौजूद नहीं है। नतीजतन, आपको प्रत्येक डॉकिटिट के बाद, या कम से कम अगले डॉकिटिट से पहले अपनी गिट शाखाओं को फिर से भरना होगा। इसका मतलब यह है नदी के ऊपर के इतिहास के पुनर्लेखन के लिए बल-जोर दे: किसी अन्य शाखाओं इस नदी के ऊपर के आधार पर कर रहे थे

git push -f origin develop 

, वे अब उस पर रिबेस करना होगा।

git-svn man page का CAVEATS अनुभाग अधिक विस्तार से जाता है, इसलिए आपको इसे निश्चित रूप से पढ़ना चाहिए।

एसवीएन पक्ष पर आपके क्लाइंट द्वारा किए गए परिवर्तन स्वचालित रूप से git svn rebase के माध्यम से आपकी विकास शाखा में शामिल हो जाएंगे, और अंततः git push -f के माध्यम से बिटबकेट तक पहुंच जाएंगे।

यदि इस प्रकार का वर्कफ़्लो आपको संतुष्ट नहीं करता है, तो यह SubGit पर देखने लायक हो सकता है। मैंने कभी कोशिश नहीं की है, लेकिन वे दो एससीएम के बीच बहुत कम सीमित एकीकरण की पेशकश करने का दावा करते हैं।