2011-02-03 16 views
7

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

उत्तर

2

एसवीएन स्विच अनदेखी फ़ाइलों को हटा नहीं पाएगा जैसा आपने पाया है।

जिस तरह से मैं इसे अपनी निर्माण प्रक्रिया (क्रूज़ कंट्रोल) में संभालता हूं, हर निर्माण के बाद हमेशा पूरे कार्य फ़ोल्डर को हटाना है। फिर जब आपकी बिल्ड प्रक्रिया एक एसवीएन प्राप्त करती है, तो यह एक खाली निर्देशिका में होगी और कोई संघर्ष नहीं होगा।

बीटीडब्ल्यू यही कारण है कि आपको एक अलग बिल्ड सर्वर का उपयोग करना चाहिए - तो आपके पास निर्माण के साथ हस्तक्षेप करने वाले असामान्य देव कार्य नहीं होंगे।

+0

मैं लगता है कि आपको मेरे प्रश्न नहीं मिला। हेड संशोधन में कुछ फ़ोल्डरों या फ़ाइलों को रिपो के लिए प्रतिबद्ध किया जाएगा, जबकि वापस स्विच करते समय, उन फ़ोल्डरों को काम करने वाली प्रतिलिपि से हटा दिया जाएगा।शाखा/टैग पर स्विच करने के बाद, काम करने वाली प्रतिलिपि नई स्विच की गई शाखा या टैग – sandy

+0

के बराबर हो, मुझे लगता है कि आप जो मतलब चाहते थे उसे याद किया .. यदि आप स्विच करने से पहले कार्यशील निर्देशिका से सभी को हटा देते हैं, तो इससे कोई फर्क नहीं पड़ता कि वहां क्या था पहले, या वर्तमान में किसी अन्य शाखा/टैग के लिए क्या प्रतिबद्ध है। आपके पास केवल उस शाखा के लिए कोड होगा जिसे आप बनाना चाहते हैं। हटाने के बाद –

+0

, क्या मैं svn स्विच कर सकता हूं, इसके बजाय मैं svn चेकआउट कर सकता हूं। क्योंकि कामकाजी प्रति खाली है? फिर svn स्विच कमांड के पूरे बिंदु को wats। अगर मैं ग़लत हूं तो मेरी गलती सुझाएं? – sandy

1

दो साल बाद ...

कुछ चारों ओर संवारता और देख अपने प्रश्न (सैंडी) जवाब है के बाद, हाँ, एक स्विच निर्देशिका हटा देना चाहिए। मुझे एक ही समस्या थी और इसे एक बाहर निकाला।

स्पष्ट होने के लिए, जैसा कि मैं समझता हूं कि यह मुद्दा यह है कि आप अपनी शाखा में एक निर्देशिका/फ़ोल्डर जोड़ते हैं, फिर ट्रंक पर वापस स्विच करें। वापस स्विच करते समय यह जोड़ा फ़ोल्डर हटा दिया जाना चाहिए।

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

4

कोई बग नहीं है लेकिन आपको यह सुनिश्चित करना होगा कि स्विचस्पेस स्विच करने से पहले वास्तव में साफ है। यदि यह साफ़ है, तो हटाएं/फ़ाइलों और डीआईआर को बनाता है जो केवल एक संस्करण में मौजूद हैं। इस अंत में उपversण 1.6 मैनुअल कहता है:

एक काम करने वाली प्रति "स्विचिंग" जिसमें एक अलग शाखा परिणाम में कोई स्थानीय संशोधन नहीं होता है, वैसे ही यह काम करता है जैसे कि आप निर्देशिका का ताजा चेकआउट करेंगे।

मैंने अभी इसे नव निर्मित परीक्षण भंडार के साथ परीक्षण किया है। यदि दूसरी ओर वर्तमान कार्यक्षेत्र में स्थानीय संशोधन हैं, तो svn उन्हें त्याग नहीं देगा। svn इस सम्मान के साथ सुंदर रूढ़िवादी है। जैसे मैंने ट्रंक पर dir निर्देशिका बनाई और इसे प्रतिबद्ध किया। तब मैंने बैकअप फ़ाइल dir/file.~1~ बनाई। यह svn st द्वारा रिपोर्ट नहीं किया गया था क्योंकि *~ वैश्विक रूप से मेरी कॉन्फ़िगरेशन के साथ अनदेखा किया गया है। जब मैंने एक शाखा svn पर वापस स्विच किया था तो dir हटा दिया जाना चाहिए था, लेकिन इससे बैकअप फ़ाइल हटा दी गई थी, इसलिए svn ने ऐसा नहीं किया। इसने निर्देशिका को स्थानीय संशोधन के रूप में रखा।

साइड नोट: ट्रंक पर फिर से स्विच करते समय svn ने एक त्रुटि की सूचना दी क्योंकि dir शाखा पर स्थानीय संशोधन के रूप में ट्रंक पर संस्करण dir के साथ संघर्ष में था। --force उस समस्या को हल किया।

+0

आपने समस्या को अच्छी तरह से पढ़ा नहीं है। "svn add", और फिर पुराने संशोधन में "svn स्विच" अनियंत्रित फ़ाइलों का कारण बनता है, लेकिन उन्हें हटा दिया जाना चाहिए। एक साफ चेकआउट के साथ, विभिन्न शाखाओं और टैगों के बीच "svn स्विच" संघर्षों का कारण नहीं बनना चाहिए - लेकिन वास्तव में यह संघर्ष का कारण बनता है। शायद मुझे एक पुन: उत्पन्न करने योग्य परिदृश्य बनाने की कोशिश करनी चाहिए ... – tobixen

+0

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

+0

ठीक है, मुझे लगता है कि शायद आप यहां कुछ पर हैं। यहां मेरा शोध एक टिप्पणी में फिट होने के लिए बहुत लंबा है, इसलिए मैं एक अलग उत्तर लिखूंगा। – tobixen

2

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

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

mkdir /tmp/workdir/ 
cd /tmp/workdir 
svnadmin create /tmp/foobar 
svn checkout file:///tmp/foobar/ 
svn mkdir foobar/tags 
svn mkdir foobar/trunk 
cd foobar 
svn commit -m "trunk and tags" 
## NOTE: in svn 1.8 and higher, it's needed with a --ignore-ancestry option below 
svn switch file:///tmp/foobar/trunk 

(और यहाँ हम पहले से ही देख सकते हैं कि यह सही बात कर रहा है - को हटाने टैग और ट्रंक उपनिर्देशिका)

touch file1 
svn add file1 
svn commit -m "added file1" 
svn cp -m "file1 in tag1" . file:///tmp/foobar/tags/tag1 

और फिर फिर से ...

touch file2 
svn add file2 
svn commit -m "added file2" 
svn cp -m "file2 in tag2" . file:///tmp/foobar/tags/tag2 

आइए स्पष्ट रूप से टैग 3

svn rm file1 
svn commit -m "deleted file1" 
svn cp -m "file1 removed from tag3" file:///tmp/foobar/trunk/ file:///tmp/foobar/tags/tag3/ 
से फ़ाइल 1 हटाएं

... और साथ ही एक नया निर्देशिका ...

svn mkdir dir1 
touch dir1/file3 
svn add dir1/file3 
svn commit -m "added dir1/file3" 
svn cp -m "dir1/file3 in tag4" file:///tmp/foobar/trunk file:///tmp/foobar/tags/tag4/ 

... और यह tag5 में डिलीट ...

svn rm dir1 
svn commit -m "removed dir1/file3" 
svn cp -m "dir1/file3 removed in tag5" file:///tmp/foobar/trunk file:///tmp/foobar/tags/tag5/ 

... और कैसे काम करता है स्विचिंग की जाँच करें। ..

svn switch file:///tmp/foobar/tags/tag1 
svn switch file:///tmp/foobar/tags/tag2 
svn switch file:///tmp/foobar/tags/tag3 
svn switch file:///tmp/foobar/tags/tag4 
svn switch file:///tmp/foobar/tags/tag5 
svn switch file:///tmp/foobar/tags/tag4 

... कोई समस्या नहीं है। लेकिन, का कहना है कि मैं संशोधित Emacs साथ dir1/file3 - यह आम तौर पर एक बैकअप फ़ाइल बनाना होगा:

touch dir1/file3~ 

इस पर डिफ़ॉल्ट SVNIGNORE सेटिंग के कारण "SVN स्थिति" दिखाई नहीं देता ...

svn status 

लेकिन यह बातें तोड़ने के लिए पर्याप्त है:

svn switch file:///tmp/foobar/tags/tag5 
svn status 
svn switch file:///tmp/foobar/tags/tag4 

पहले आदेश इंगित करता है कि dir1 हटा दी जाती है, लेकिन unrevisioned फ़ाइल के कारण निर्देशिका खड़े हो जाता है।

unrevisioned फ़ाइलें "SVN वापस लौटने" दुर्भाग्य से दूर नहीं करता ...

svn revert -R . 
svn switch file:///tmp/foobar/tags/tag5 
svn status 
svn switch file:///tmp/foobar/tags/tag4 

"स्वच्छ बनाने के" और काम नहीं हो सकता है, पर्यावरण के आधार पर। एक निश्चित रूप से इसे हटाने के लिए एक स्क्रिप्ट है, यानी इस तरह बना सकते हैं:

rm -rf $(svn status --no-ignore | grep -E '^\?' | awk ' { print $2 ; }') 
svn switch file:///tmp/foobar/tags/tag4 

कृपया ध्यान दें कि आदेश ऊपर बैड थिंग्स ऐसा कर सकते हैं जब रिक्तियों के साथ फ़ाइल नाम का सामना।

एक भी उपयोग करके ऊपर कुछ त्रुटि संदेश से बचने कर सकते हैं "--force":

touch dir1/file3~ 
svn switch --force file:///tmp/foobar/tags/tag5 
svn switch --force file:///tmp/foobar/tags/tag4 

ध्यान दें कि mydir1/file3 ~ कभी नहीं नष्ट कर दिया जाता है, लेकिन पिछले स्विच असफल नहीं हो कि

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