'Svn cleanup' विफल होने पर मुझे क्या करना चाहिए?




(20)

मेरे पास एक काम करने वाले फ़ोल्डर में बहुत सारे बदलाव हैं, और कुछ अपडेट करने की कोशिश कर खराब हो गया है।

अब जब मैं 'svn cleanup' जारी करता हूं तो मुझे मिलता है:

>svn cleanup .
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'MemPoolTests.cpp' is not under version control

MemPoolTests.cpp एक नई फाइल है जो एक और डेवलपर जोड़ा गया है और अपडेट में लाया गया था। यह पहले मेरे काम करने वाले फ़ोल्डर में मौजूद नहीं था।

क्या रिपोजिटरी की ताजा प्रति जांचने के बिना मैं कुछ भी करने और आगे बढ़ने के लिए कर सकता हूं?

स्पष्टीकरण: निर्देशिका को रास्ते से बाहर ले जाने और एक नई प्रतिलिपि लाने के सुझावों के लिए धन्यवाद। मुझे पता है कि यह एक विकल्प है, लेकिन यह एक है जिसे मैं टालना चाहता हूं क्योंकि कई निर्देशिकाएं घनिष्ठ कई निर्देशिकाएं हैं (यह एक शाखा होनी चाहिए ...)

मैं सफाई करने का एक और आक्रामक तरीका उम्मीद कर रहा हूं, शायद फ़ाइल को एसवीएन को मजबूर करने के किसी भी ज्ञात राज्य में परेशानी हो रही है (और मैंने इसकी कामकाजी प्रतिलिपि हटाने की कोशिश की ... जो मदद नहीं करता)।


(इससे पहले कि आप फ़ोल्डर को स्थानांतरित करने और एक नया चेकआउट करने का प्रयास करें।)

फ़ोल्डर को अपमानजनक फ़ाइल में हटाएं - हाँ, यहां तक ​​कि .svn फ़ोल्डर, फिर शीर्ष / मूल फ़ोल्डर पर एक svn cleanup करें।


इसी तरह के मुद्दे का सामना करते समय, रिपोजिटरी सिंक व्यू में मैन्युअल विलय ने इस मुद्दे को हल करने में मदद की।

एक फ़ाइल का नाम दूसरे के साथ विवादित था और यह स्पष्ट रूप से इस मुद्दे का उल्लेख करता था। नई फ़ाइल को किसी दूसरे नाम पर पुनर्नामित करने से इसे हल किया गया।


जब भी मुझे समान समस्याएं होती हैं तो मैं इस तरह की सहायता के लिए rsync (एनबी: मैं लिनक्स या मैक ओएस एक्स का उपयोग करता हूं) का उपयोग करता हूं:

# Go to the parent directory
cd dir_above_borked

# Rename corrupted directory
mv borked_dir borked_dir.bak

# Checkout a fresh copy
svn checkout svn://... borked_dir

# Copy the modified files to the fresh checkout
# - test rsync
#   (possibly use -c to verify all content and show only actually changed files)
rsync -nav --exclude=.svn borked_dir.bak/ borked_dir/

# - If all ok, run rsync for real
#   (possibly using -c again, possibly not using -v)
rsync -av --exclude=.svn borked_dir.bak/ borked_dir/

इस तरह आपके पास एक नया चेकआउट है, लेकिन एक ही काम करने वाली फाइलों के साथ। मेरे लिए यह हमेशा एक आकर्षण की तरह काम करता है।


जब मुझे टोर्टोइज एसवीएन (विंडोज) के साथ इस समस्या का सामना करना पड़ता है, तो मैं Cygwin जाता हूं और वहां से ' svn cleanup ' चलाता हूं; यह मेरे लिए सही ढंग से साफ हो जाता है, जिसके बाद सब कुछ TortoiseSVN से काम करता है।


नवीनतम संस्करण (मैं 1.9.5 का उपयोग कर रहा हूं) साफ़ अप मेनू पर "ब्रेक लॉक" का एक विकल्प जोड़कर इस समस्या को हल करता हूं। बस यह सुनिश्चित करें कि साफ-सफाई करते समय यह चेक बॉक्स चुना गया है।


नहीं नहीं नहीं! यदि आप एसवीएन 1.7 या उच्चतर का उपयोग कर रहे हैं, तो क्लीनअप कमांड को नौकरी करना चाहिए!

मैंने कुछ प्रयोग भी किए और पाया कि समाधान (कम से कम Eclipse ) केवल त्रुटि संदेश में निर्दिष्ट फ़ोल्डर के लिए सफाई को निष्पादित कर रहा था, न कि पूरी परियोजना!


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

कई परिस्थितियों में Windows क्लाइंट क्लीनअप कमांड नहीं चलाएगा, लेकिन क्लीनअप SVN कमांड लाइन उपयोगिता का उपयोग करके ठीक काम करता है।


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


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


मेरे साथ भी ठीक यही समस्या थी। मैं प्रतिबद्ध नहीं कर सका, और सफाई विफल हो जाएगी।

कमांड लाइन क्लाइंट का उपयोग करके मैं एक त्रुटि संदेश देख रहा था जो इंगित करता है कि यह .svn/props से .svn/prop-base फ़ाइल को स्थानांतरित करने में विफल रहा था।

मैंने विशिष्ट फ़ाइल को देखा और पाया कि इसे केवल पढ़ने के लिए चिह्नित किया गया था। केवल-पढ़ने योग्य विशेषता को हटाने के बाद मैं फ़ोल्डर को साफ़ करने और मेरे परिवर्तनों को करने में सक्षम था।


मैंने sudo chmod 777 -R . किया था sudo chmod 777 -R . अनुमतियों को बदलने में सक्षम होने के लिए। sudo बिना, यह काम नहीं करेगा, मुझे अन्य आदेशों को चलाने के समान त्रुटि दे रहा है।

अब आप अपनी संपूर्ण निर्देशिका को स्क्रैप किए बिना और इसे पुन: बनाने के बिना, svn update या जो कुछ भी कर सकते हैं। यह विशेष रूप से सहायक है, क्योंकि आपके आईडीई या टेक्स्ट एडिटर में पहले से कुछ टैब खुल सकते हैं, या समस्याओं को सिंक कर सकते हैं। आपको इस विधि के साथ अपनी कार्यशील निर्देशिका को स्क्रैप और प्रतिस्थापित करने की आवश्यकता नहीं है।


मैंने एक मुद्दा जारी किया जहां एक अद्यतन के बाद, एसवीएन ने एक फ़ोल्डर को विवादित दिखाया। आश्चर्यजनक रूप से, यह केवल कमांड लाइन के माध्यम से दिखाई देता था - TortoiseSVN ने सोचा कि यह ठीक था।

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup , svn revert , svn update और svn resolve इसे ठीक svn resolve में असफल रहे।

अंत में मैंने समस्या को हल किया:

  • "Sub_dir" के लिए .svn निर्देशिका में देखें
  • प्रविष्टियों फ़ाइल पर 'केवल पढ़ने' ध्वज को अनचेक करने के लिए आरसी -> गुणों का उपयोग करें
  • प्रविष्टियों की फ़ाइल खोलें और "अधूरा ..." और संबंधित चेकसम को हटाएं
  • सहेजें, और केवल पढ़ने के ध्वज को फिर से सक्षम करें
  • My_dir निर्देशिका के लिए दोहराएं

उसके बाद, सबकुछ ठीक था।

नोट: मेरे पास कोई स्थानीय परिवर्तन नहीं था, इसलिए मुझे नहीं पता कि अगर आप ऐसा करते हैं तो आपको जोखिम होगा या नहीं। मैंने दूसरों द्वारा सुझाए गए डिलीट / अपडेट विधि का उपयोग नहीं किया - मैं इस राज्य में my_dir / sub_dir / sub_sub_dir निर्देशिका (जो एक ही लक्षण से शुरू हुआ) पर कोशिश कर रहा था - इसलिए मैं चीजों को और खराब करने का जोखिम नहीं लेना चाहता था फिर!

काफी विषय नहीं है, लेकिन अगर कोई इस पोस्ट में आता है तो मैं सहायक हो सकता हूं।


मैंने कुछ सहयोगी की .svn निर्देशिका को मेरी प्रतिलिपि बनाकर और फिर मेरी कार्यशील प्रति को अपडेट करके इस समस्या को हल किया। यह एक अच्छा, त्वरित और साफ समाधान था।


मैंने यहां समझाए गए विभिन्न समाधानों की कोशिश की, लेकिन कोई भी काम नहीं किया।

मेरे मामले में, (एसवीएन 1.9.3), ग्रहण पर चल रहा है, टीमसिर पर अद्यतन त्रुटि के साथ विफल रहता है:

svn: E155004: '/ home / user / path / to / svn-folder' में अधूरा कार्य आइटम हैं; पहले 'svn cleanup' चलाएं।

टीमसफाई एक ही त्रुटि के साथ विफल रहता है।

मेरे लिए एक सरल समाधान मिला: मैं कमांड लाइन में क्लीनअप चला गया :

~/path/to/svn-folder/$ svn cleanup

आदेश सफल हुआ। फिर ग्रह → ग्रहण में अद्यतन फिर से काम किया।


यदि समस्या केस संवेदनशीलता है (जो मैक, साथ ही विंडोज़ पर जांच करते समय कोई समस्या हो सकती है) और आपके पास * निक्स सिस्टम पर जांच करने का विकल्प नहीं है, तो निम्न कार्य करना चाहिए। शुरुआत से ही प्रक्रिया यहां दी गई है:

% svn co http://[domain]/svn/mortgages mortgages

(चेकआउट ensues ... तो ...)

svn: In directory 'mortgages/trunk/images/rates'
svn: Can't open file 'mortgages/trunk/images/rates/.svn/tmp/text-base/Header_3_nobookmark.gif.svn-base': No such file or directory

यहां एसवीएन समान नामों वाली दो फाइलों की जांच करने की कोशिश कर रहा है जो केवल मामले के आधार पर भिन्न हैं - Header_3_noBookmark.gif और Header_3_nobookmark.gif । मैक फाइल सिस्टम इस तरह की परिस्थितियों में एसवीएन को चकित करने के कारण इस तरह असंवेदनशीलता के मामले में डिफ़ॉल्ट है। इसलिए...

% cd mortgages/trunk/images/rates/
% svn up
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

हालांकि, svn cleanup चलाना काम नहीं करता है, जैसा कि हम जानते हैं।

% svn cleanup
svn: In directory '.'
svn: Error processing command 'modify-wcprop' in '.'
svn: 'spacer.gif' is not under version control

spacer.gif यहां समस्या नहीं है ... यह पिछली त्रुटि को पिछली फ़ाइल में स्थानांतरित नहीं कर सकता है। तो मैंने .svn अलावा निर्देशिका से सभी फ़ाइलों को हटा दिया, और एसवीएन लॉग हटा दिया। इसने क्लीनअप काम किया, ताकि मैं अपमानजनक फ़ाइल को देख और नाम बदल सकूं।

% rm *; rm -rf .svn/log; svn cleanup
% svn up Header_3_nobookmark.gif
A    Header_3_nobookmark.gif
Updated to revision 1087.
% svn mv Header_3_nobookmark.gif foo
A         foo
D         Header_3_nobookmark.gif
% svn up
A    spacer.gif
A    Header_3_noBookmark.gif

इसके बाद, मैं प्रोजेक्ट की मूल निर्देशिका पर वापस जाने में सक्षम था, और बाकी के बाकी हिस्सों को देखने के लिए svn up चलाता हूं।


यह संभव है कि आपको केवल दो फ़ाइल नामों के साथ समस्या हो, जो केवल अपरकेस से अलग हो। यदि आप इस समस्या में भाग गए हैं, तो एक और काम करने वाली प्रतिलिपि बनाने की समस्या समस्या को हल नहीं करती है।

वर्तमान विंडोज (यानी FILEname ) फाइल सिस्टम बस Filename और Filename बीच अंतर को कम नहीं करते हैं। आपके पास दो संभावित फिक्स हैं:

  1. वास्तविक फाइल सिस्टम (यूनिक्स-आधारित) के साथ प्लेटफ़ॉर्म पर देखें, फ़ाइल का नाम बदलें, और परिवर्तन करें।
  2. जब आप विंडोज़ में स्टॉक होते हैं तो आप एक्लिप्स एसवीएन रिपोजिटरी ब्राउज़र में फ़ाइलों का नाम बदल सकते हैं जो अंतर को पहचानते हैं और वहां फ़ाइल का नाम बदलते हैं।
  3. आप समस्याग्रस्त फ़ाइलों का नाम बदलकर किसी भी कमांड लाइन एसवीएन क्लाइंट से svn rename -m "broken filename case" http://server/repo/FILEname http://server/repo/filename का उपयोग कर दूरस्थ रूप से पुनर्नामित कर सकते हैं

यहां उद्धृत किए गए अधिकांश समाधानों के माध्यम से जाने के बाद, मुझे अभी भी त्रुटि मिल रही थी।

मुद्दा मामला असंवेदनशील ओएस एक्स था । एक निर्देशिका की जांच करना जिसमें एक ही नाम वाली दो फाइलें हैं, लेकिन अलग-अलग पूंजीकरण एक समस्या का कारण बनता है। उदाहरण के लिए, ApproximationTest.java और Approximationtest.java एक ही निर्देशिका में नहीं होना चाहिए। जैसे ही हम फ़ाइल में से किसी एक से छुटकारा पा लेते हैं, समस्या दूर हो जाती है।


यहां दिए गए उत्तरों ने मेरी मदद नहीं की, लेकिन परियोजना को फिर से जांचने से पहले, मैंने बंद कर दिया और ग्रहण खोला (सबवर्सिव मेरा एसवीएन क्लाइंट है) और समस्या गायब हो गई।


विंडोज़ के साथ नेटवर्क ड्राइव पर कभी-कभी केवल पढ़ने के लिए लॉकिंग होती है। डिस्कनेक्ट करने और फिर से कनेक्ट करने का प्रयास करें। फिर सफाई और अद्यतन करें।


यह उत्तर केवल 1.7 से पहले संस्करणों पर लागू होता है (धन्यवाद @ ŁukaszBachman)

सबवर्सन प्रति फ़ोल्डर (.svn में) की जानकारी संग्रहीत करता है, इसलिए यदि आप केवल उपफोल्डर से निपट रहे हैं तो आपको पूरे भंडार को चेकआउट की आवश्यकता नहीं है - केवल उस फ़ोल्डर को जो बोर्क किया गया है:

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

यह आपको बोर्क किए गए फ़ोल्डर की एक अच्छी कामकाजी प्रतिलिपि देगा, लेकिन आपके पास अभी भी borked_dir.bak में आपके परिवर्तनों का बैक अप लिया गया है। विंडोज / टोर्टोइज एसवीएन के साथ एक ही सिद्धांत लागू होता है।

यदि आपके पास एक अलग फ़ोल्डर में परिवर्तन हैं तो देखें

svn checkout -N borked_dir   # Non-recursive, but deprecated

या

svn checkout --depth=files borked_dir
# 'depth' is new territory to me, but do 'svn help checkout'




svn