2010-05-14 12 views
28

के लिए रीसेट ट्रैकिंग मैं एसवीएन रिपोजिटरी के साथ काम करने के लिए git-svn का उपयोग कर रहा हूं। मेरी कामकाजी प्रतियां git svn clone -s http://foo.bar/myproject का उपयोग करके बनाई गई हैं ताकि मेरी कार्यशील प्रतिलिपि एसवीएन (ट्रंक, टैग, शाखाओं) के लिए डिफ़ॉल्ट निर्देशिका योजना का पालन करे।गीट-एसवीएन: मास्टर

हाल ही में मैं एक शाखा पर काम कर रहा हूं जो git-svn branch myremotebranch का उपयोग करके बनाया गया था और git checkout --track -b mybranch myremotebranch का उपयोग करके चेक-आउट किया गया था। मुझे कई स्थानों से काम करने की ज़रूरत थी, इसलिए शाखा I git-svn dcommit -ed फ़ाइलों से नियमित रूप से एसवीएन भंडार में।

मेरे परिवर्तनों को पूरा करने के बाद, मैंने मास्टर पर वापस स्विच किया और एक विलय निष्पादित किया, विलय किया, और रिमोट ट्रंक में सफल विलय को कम करने की कोशिश की।

ऐसा लगता है जैसे कि मर्ज के बाद गुरु के लिए दूरदराज के ट्रैकिंग शाखा में स्विच करने की है मैं पर काम कर रहा था:

# git checkout master 
# git merge mybranch 
... (successful) 
# git add . 
# git commit -m '...' 
# git svn dcommit 
Committing to http://foo.bar/myproject/branches/myremotebranch ... 
# 

वहाँ एक रास्ता इतना है कि यह रूप में remotes/trunk अनुसरण कर रहा है मैं मास्टर को अपडेट कर सकते है विलय से पहले?

मैं गिट 1.7.0.5 का उपयोग कर रहा हूं, अगर यह कोई मदद है।

यह उपयोगी होगा यदि आप क्यों समझा सकते हैं ऐसा क्यों हुआ, इसलिए मैं फिर से होने वाली समस्या से बच सकता हूं। धन्यवाद!

संपादित करें:

यहाँ मेरे वर्तमान .git/config है:

[core] 
    repositoryformatversion = 0 
    filemode = true 
    bare = false 
    logallrefupdates = true 
    autocrlf = false 
[svn-remote "svn"] 
    url = http://foo.bar/myproject 
    fetch = trunk:refs/remotes/trunk 
    branches = branches/*:refs/remotes/* 
    tags = tags/*:refs/remotes/tags/* 
[branch "mybranch"] 
    remote = . 
    merge = refs/remotes/myremotebranch 

तो ऐसा लगता है कि ट्रंक सही जगह की ओर इशारा करते है। हालांकि, शाखा में स्विच करने के बाद मास्टर को वापस मदद नहीं करता है; मास्टर में git svn dcommit अभी भी myremotebranch पर धक्का देने का प्रयास करता है।

उत्तर

22

जब ट्रंक पर कोई बदलाव नहीं होता है, तो गिट एक तेज़-आगे विलय करता है और बस आपकी शाखा पर प्रतिबद्ध करने के लिए स्थानीय "मास्टर" शाखा सेट करता है। गिट-एसवीएन को पता नहीं है कि कैसे तेजी से आगे बढ़ना ट्रंक में विलय हो जाता है, वास्तव में ऐसा लगता है कि "मास्टर" अब एसवीएन शाखा को इंगित कर रहा है।

इसके आसपास काम करने के लिए, git merge --no-ff विलय करते समय उपयोग करें। इससे गेट को एक मर्ज प्रतिबद्ध बनाने के लिए मजबूर किया जाएगा, जिसे बाद में svn में डिक्यूटेड किया जा सकता है।

+1

'--no-ff' पर अच्छा बिंदु। +1 – VonC

+0

स्पष्टीकरण के लिए, यदि मैं समझता हूं, तो गिट उस प्रतिबद्धता का उपयोग करता है जो "मास्टर" पॉइंटर तय करता है कि कौन सी एसवीएन शाखा प्रतिबद्ध है। यही कारण है कि एसवीएन डॉकिट कदम विफल हो जाता है, क्योंकि आपने विलय पूरा करने के बाद, और 'माइब्रैंच' और 'मास्टर' एक ही प्रतिबद्धता पर हैं। यह प्रतिबद्धता मूल रूप से 'myremotebranch' एसवीएन शाखा से बनाई गई थी। – cmcginty

+2

मुझे नहीं लगता कि एक नया विलय प्रतिबद्धता मामलों को स्पष्ट करने में मदद करने जा रही है, क्योंकि जब भी यह svn भंडार के लिए प्रचारित होता है तो मर्ज जानकारी खो जाएगी। –

5

यदि आपने मास्टर पर कोई प्रतिबद्धता नहीं की है, तो इसका मतलब है कि git merge mybranch एक तेज़ आगे वाला था: master HEAD बस mybranch HEAD पर जाएं।

यह बता सकता है कि git svn dcommit ने आपके परिवर्तन SVN mybranch पर क्यों धक्का दिया।
यह होगा:

  • पहले अद्यतन पिछले Git mybranch साथ इसी SVN शाखा अभी तक dcommitted नहीं करता है,
  • रिकॉर्ड मर्ज SVN पक्ष
  • पर ट्रंक करने के लिए और फिर उस पर मास्टर rebase हैं गिट साइड (कुछ भी करने के लिए नहीं, पहले से ही वहाँ)।

मुझे नहीं लगता कि गुरु अपने संदर्भ में परिवर्तन नहीं किया गया है, लेकिन यदि आप एक संदेह है (और अपने कार्यशील निर्देशिका साफ है), तो आप (यदि गुरु अभी चेक आउट किया जाता है) हो सकता है:

git reset --hard remotes/trunk 
+0

ऐसा लगता है कि रीसेट करना, मास्टर पर कुछ बदलना, 'डॉकिटिटिंग', फिर फिर से विलय करना, इसलिए एक संघर्ष है, उस संघर्ष को ठीक करना, फिर 'dcommit'ing समस्या को हल करता है। हालांकि यह सुखद नहीं है। –

+0

@ डिजीटाला: आपका मतलब है कि अकेले रीसेट पर्याप्त नहीं है? रीसेट के बाद पहला डॉकिट एसवीएन ट्रंक पर नहीं होता है? – VonC

4

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

मुझे पूरी तरह से यकीन नहीं है कि आपका एसवीएन रिपोजिटरी किस स्थिति में है - मैं यह सुनिश्चित करने के लिए जांच करूँगा कि मर्ज डॉकिट ने जो किया वह आपको ट्रंक पर करना चाहता था। यहां तक ​​कि अगर ऐसा हुआ, तो मैं शर्त लगाता हूं कि यदि आप अपने रेपो में refs/heads/master और refs/remotes/trunk फ़ाइलों की सामग्री देखते हैं, तो आप देखेंगे कि वे इस समय अलग हैं। यदि ऐसा है, तो मैं गिट-एसवीएन ट्रैकिंग शाखा के साथ गिट शाखा को पुनर्वित्त करने के लिए के बाद के बाद (कोई स्थानीय परिवर्तन मौजूद नहीं होगा)। यदि आपके पास स्थानीय परिवर्तन हैं, तो आपको git rebase master^4 --onto remotes/trunk जैसे कुछ करना होगा और ऐसा करना होगा, जहां 4 आपको संरक्षित करने की आवश्यकता वाले कामों की संख्या है। वैकल्पिक रूप से, यदि वे सभी असामान्य हैं, तो उन्हें पहले git stash के साथ छेड़छाड़ करें।

विफल होने पर, आप हमेशा सबकुछ svn में प्राप्त कर सकते हैं और केवल रेपो को मिटा सकते हैं और एक नया चेकआउट प्राप्त कर सकते हैं।

+0

मैं उस विश्लेषण से सहमत हूं। +1 – VonC

0

मैं एक ही समस्या थी, और मैं मास्टर जिसके बाद Git SVN जानकारी वापस ओर इशारा में वापस रिमोट/ट्रंक विलय कर दिया ट्रंक को

मैं समय dcommit दरअसल करने के लिए नहीं था और जैसा कि मैंने परियोजना छोड़ने गया था मेरी गिट-एसवीएन रेपो मेरी बुरी तरह से मर गया। मैंने डॉकिट-ड्राई-रन की कोशिश की और कहा कि यह ट्रंक पर वापस आ जाएगा।

मैं सेटअप और परीक्षण पुन: पेश जब मैं वापस गुरु छोड़ने के बाद भी समय

चियर्स

12

आप तो git svn rebase हो और का उपयोग --squash आप इस से बच सकते हैं करेंगे।

# git checkout master 
# git svn rebase //(<--the missing step) 
# git merge --squash mybranch // (<-- doesn't commit, more like an svn merge would do) 
... (successful) 
# git add . 
# git commit -m '...' 
# git svn dcommit 
Committing to http://foo.bar/myproject/trunk... 
# 

वर्तमान स्थिति (यानी अपने गुरु एक SVN शाखा की ओर इशारा करते है) को हल करने के

आप किसी अन्य शाखा करने के लिए 'स्विच', गुरु, यह करने के लिए 'स्विच' वापस हटा सकते हैं और उसके बाद फिर विलय:

# git checkout mybranch 
# git branch -D master 
# git checkout -b master trunk 
... continue with merge... 
# git merge --squash mybranch 

... अब आप mybranch commit के लिए मास्टर और तैयार में विलय कर दिया और उसके बाद dcommit करने के लिए है trunk

+1

'इस स्थिति को हल करने' सहित, इस स्पष्टीकरण के लिए बहुत बहुत धन्यवाद। मैं एक ही अचार में था, और यह इसे हल करने के लिए बहुत अच्छी तरह से काम किया। – sockmonk

+2

मुझे नहीं लगता कि 'गिट चेकआउट -बी मास्टर ट्रंक' सही है। यह 'गिट चेकआउट -बी मास्टर रिमोट्स/गिट-एसवीएन' – janos

+0

होना चाहिए यदि आप "गिट-एसवीएन" नामक एक एसवीएन शाखा पर काम करना चाहते हैं (यानी मर्ज करें), लेकिन यदि आप ट्रंक में विलय करने की कोशिश कर रहे हैं और आपका एसवीएन रेपो "मानक" है (उदाहरण के लिए एक ही डीआईआर में/शाखाएं/टैग/ट्रंक है) तो 'गिट चेकआउट -बी मास्टर ट्रंक' निश्चित रूप से सही है – dyodji

3

हमने गिट-एसवीएन फीचर शाखा विकास में सफलतापूर्वक git merge --squash का उपयोग किया है। गिट-एसवीएन के साथ समस्या यह है कि जब आपका स्थानीय गिट-एसवीएन क्लोन मर्ज जानकारी संग्रहीत कर सकता है, एक बार जब आप svn भंडार को कम कर देते हैं, तो यह खो जाता है।

तो अन्य (git-) svn उपयोगकर्ताओं के लिए मर्ज काम करता है जैसे सादे काम करता है। स्क्वैश git merge --no-ff (उदाहरण के लिए मास्टर पर विलय प्रतिबद्धता का उत्पादन) के लिए अच्छा है, लेकिन इसमें शाखा में किए गए वास्तविक कामों की एक सूची भी शामिल है, जो अन्यथा खोने पर खो जाएगी।

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