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


245

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

अब जब मैं एक 'svn सफाई' जारी करता हूँ:

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

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

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

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

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


पुन: एक नई प्रति का उपयोग करना। एक दूसरे के खिलाफ संस्करणों को अलग करने की तुलना में परे की एक प्रति पकड़ो
जॉन विंस्टनले

2
क्या अमीन का हल आपके काम नहीं आया? निश्चित रूप से एक स्पष्ट जवाब अन्यथा स्वीकार करने के लिए?
एलिस परसेल

2
सुनिश्चित करें कि किसी भी फ़ाइल को किसी एप्लिकेशन द्वारा खुला नहीं रखा गया है, इसे भूलना आसान है। प्रक्रिया एक्सप्लोरर और रास्ते पर एक त्वरित खोज यह उजागर करने के लिए बहुत उपयोगी है: Technet.microsoft.com/en-us/sysinternals/bb896653.aspx
angularsen

4
IMHO "svn cleanup" कमांड का अस्तित्व विफलता का एक प्रवेश है।
योयो

जवाबों:


223

जब सब शुरू करना एक विकल्प नहीं है ...

मैंने .svnनिर्देशिका में लॉग फ़ाइल को हटा दिया (मैंने भी अपमानजनक फ़ाइल को हटा दिया .svn/props-base), एक सफाई की, और अपना अपडेट फिर से शुरू किया।


3
मुझे यहां मूल प्रश्न के समान समस्या थी (एक बाधित svn चेकआउट के कारण)। इसने मेरे लिए इसे ठीक कर दिया। हालाँकि मुझे भी मूल निर्देशिका में जाना था और वहाँ भी यही करना था।
निगेल हॉकिन्स

2
+1 मैं यह नहीं बता सकता कि मैं इस स्थिति में कितनी बार गया हूं। जब यह एक सब-उप फ़ोल्डर कोई समस्या नहीं है, तो बस पूरे फ़ोल्डर को हटा दें, सफाई करें और अपडेट करें। लेकिन जब यह रूट स्तर में एक फ़ाइल है, तो यह एक सस्ता विकल्प नहीं है (पूरे प्रोजेक्ट को फिर से जांचने के लिए कई घंटे)। शानदार टिप - बहुत धन्यवाद।
इवान मेकपीस

9
मेरे लिए लॉक फ़ाइलों को हटाने का काम किया। शायद किसी के लिए ब्याज की हो। आप उन्हें निम्न आदेश के साथ पुनरावर्ती रूप से हटा सकते हैं: rm -rffind . -type f -name lock
H6

1
खुश-कोडिंग का आदेश काम नहीं करता है। यह करता है:sudo rm -rf | find . -type f -name lock
Zachary Schuessler

2
मुझे नहीं मिला.svn/prop-base.svn/[pristine|tmp|entries|format|wc.db]
bigpony

112

एसवीएन 1.7 के साथ चीजें बदल गई हैं, और लॉग फ़ाइल को .svn निर्देशिका में हटाने का लोकप्रिय समाधान डेटाबेस में काम करने-कॉपी कार्यान्वयन के लिए संभव नहीं है।

यहां मैंने वही किया जो काम करने के लिए लग रहा था:

  1. अपनी वर्किंग कॉपी के लिए .svn डायरेक्टरी को डिलीट करें।
  2. एक नई, अस्थायी निर्देशिका में एक नया चेकआउट शुरू करें।
  3. चेकआउट रद्द करें (हम सब कुछ नीचे खींचने के लिए इंतजार नहीं करना चाहते हैं)।
  4. इस रद्द किए गए चेकआउट पर क्लीनअप चलाएं।
  5. अब हमारे पास एक साफ डेटाबेस के साथ एक नई .svn निर्देशिका है (हालांकि नहीं / कुछ फाइलें)
  6. इस .svn को अपने पुराने, दूषित कार्य निर्देशिका में कॉपी करें।
  7. भागो svn अद्यतन और यह आपके पुराने आंशिक निर्देशिका निर्देशिका के साथ गति करने के लिए अपने नए आंशिक। Svn निर्देशिका लाना चाहिए।

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

मैंने अभी टीएसवीएन में यह किया है और यह ठीक काम करता है और पूर्ण चेकआउट और डाउनलोड की आवश्यकता नहीं है।

-Jody


8
मुझे ऐसा लगता है कि महीने में कम से कम दो बार ऐसा करें। कितना दर्द। Svn टीम को थिसिस चरण जोड़ना चाहिए svn cleanup --force। और निश्चित रूप से सभी जोड़ते हैं, हटाते हैं और (1.8 के साथ) नाम बदलने के संचालन खो जाते हैं।
मार्टिन

2
@ Adgezaza हां। हाँ यह करता है।
एमजे

1
इसे मेरे लिए ठीक करें। यह थोड़ा अलग है: svn को बदलने के बाद, अपडेट 1 विशिष्ट फ़ोल्डर के लिए विफल हो जाता है। उस फ़ोल्डर को हटा दें और सब कुछ ठीक है
Hoàng Long

@Pup, यह चाहिए। अनिवार्य रूप से आप बस एक नए चेकआउट के लिए मेटाडेटा नीचे खींच रहे हैं और फिर इसे फ़ाइलों के साथ आबाद कर रहे हैं। SVN यह निर्धारित करेगा कि फाइलें मेटाडेटा से मेल खाती हैं या नहीं। लेकिन, तुम्हें पता है, सब कुछ पहले मामले में ज़िप ...
JKoplo

1
मैंने एसवीएन (कछुआ एसवीएन 1.8) को फिर से स्थापित किया, मेरे प्रोजेक्ट से प्रत्येक, svn फ़ोल्डर को फिर से जारी किया, फिर यहां और वॉइला में उल्लिखित ऑपरेशन किए! लेखक को धन्यवाद!
दिमित्री

110

पर एक नज़र डालें

http://www.anujvarma.com/svn-cleanup-failedprevious-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

उपरोक्त लिंक से फिक्स का सारांश (अनुज वर्मा को धन्यवाद)

  1. Http://www.sqlite.org/download.html से sqlite कमांड-लाइन शेल (sqlite-tools-win32) स्थापित करें

  2. sqlite3 .svn/wc.db "select * from work_queue"

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

  1. sqlite3 .svn/wc.db "delete from work_queue"

बस। अब, आप फिर से सफाई चला सकते हैं - और यह काम करना चाहिए। या आप उस कार्य के लिए सीधे आगे बढ़ सकते हैं जिसे आप क्लीनअप चलाने के लिए प्रेरित करने से पहले कर रहे थे (एक नई फ़ाइल आदि जोड़कर)।


ध्यान दें कि लिंक-केवल उत्तर हतोत्साहित किए जाते हैं, एसओ उत्तर एक समाधान के लिए खोज का अंतिम बिंदु होना चाहिए (बनाम संदर्भों का एक और ठहराव, जो समय के साथ बासी हो जाते हैं)। लिंक को संदर्भ के रूप में रखते हुए कृपया यहां एक स्टैंड-अलोन सिनोप्सिस जोड़ने पर विचार करें।
क्लेओपेट्रा

8
फ़ायरफ़ॉक्स में sqlite प्रबंधक एक्सटेंशन है जो .svn / wc.db फ़ाइल को खोल और संपादित कर सकता है। Work_queue पर बराबर संचालन करने के लिए एक सुविधाजनक GUI प्रदान करता है।
जादूगर

यदि आपके पास SVN और Firefox का हालिया संस्करण है, तो sqlite प्रबंधक एडऑन 30 सेकंड में इस समस्या का ध्यान रखता है। निर्देशिकाओं को हटाने या Repobrowser का उपयोग करने के बारे में चिंता न करें। 2016 में मुझे लगता है कि यह स्वीकार किए जाते हैं जवाब होना चाहिए
arbit

5
मेरे लिए 'WC_LOCK से हटाएं?' साथ ही आवश्यक है।
ट्रिस्टन.लिउ

पूरी तरह से काम! Svn बेकार है! लेकिन work_queue से हटाने के बाद svn मुझे एक अन्य त्रुटि "svn लॉक" दें, बस कछुआ के साथ चलाएं (ग्रहण का विकल्प नहीं है) "ब्रेक ताले" से चेक
अप करें

42

यदि सभी अन्य विफल होते हैं:

  1. एक नए फ़ोल्डर में देखें।
  2. अपनी संशोधित फ़ाइलों को कॉपी करें।
  3. में वापस जाँच करें।
  4. इसे हटाने और नए का उपयोग करने से पहले पुराने फ़ोल्डर को कहीं ऊपर (आप कभी नहीं जानते + व्यामोह अच्छा है)।

27

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

ग्रहण खिड़की


अब इतना स्पष्ट लगता है! साभार
बिली जेक ओ'कॉनर

एक जादू की तरह काम किया!
विश्वनाथ

मेरे लिए अच्छा काम करता है।
सर्गेई

काम किया! जब मैंने इस समाधान को देखा तो मुझे तुरंत पता चल गया कि समस्या क्या है ... (मुझे लगता है): मेरे पास एक एक्सेल अभी भी खुला था, जो इसे संशोधित करता है। मैं कुछ जावा फ़ाइलों में अपने परिवर्तन करना चाहता था और एक्सेल फाइल देखी और "मैं वहाँ कोई परिवर्तन नहीं किया ... वापस" की तरह था। जो काम नहीं किया, तो मुझे एहसास हुआ कि यह अभी भी खुला है, इसे बंद कर दिया, F5, कमिट में दिखाई नहीं दिया, इसलिए प्रतिबद्ध होने के लिए आगे बढ़ें। और फिर यह मुझे बताता है "pls रन क्लीनअप" और वहां से मैं अटक गया था। तो धन्यवाद! :)
BAERUS

16

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

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

cd dir_above_borked
mv borked_dir borked_dir.bak
svn update borked_dir

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

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

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'

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

यह मेरे लिए काम करता है - मैंने जो कुछ किया था svn upवही रेपो था svn upजो एक अलग टैब में एक के बीच में था - मैं भूल गया था कि मैंने ऐसा किया था और इसे रात पहले ही अधूरा छोड़ दिया था।
जॉन जेड

अब सच नहीं है - नवीनतम संस्करण के साथ एसवीएन अब केवल एक .svnनिर्देशिका का उपयोग कर रहा है ।
atukaszBachman

9
$ ls -la .svn
$ rm -f .svn/lock

फिर

$ svn update

आशा करता हूँ की ये काम करेगा


6

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

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

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


मैंने उस पेड़ को छोड़ दिया, और अंत में एक नया मिला। लेकिन अगली बार जांच करने के लिए कुछ पर संकेत के लिए धन्यवाद।
रोब वॉकर

हा ... मैंने भी {नाम} से {नाम} _old में .svn \
_ प्रधान

5

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

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

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

यह मेरी समस्या है; एक सहकर्मी ने किसी तरह से कई Xcode प्रोजेक्ट फ़ाइलों की जांच करने में कामयाबी हासिल की, जिनमें से प्रत्येक की दो प्रतियाँ केवल पत्र का मामला है। मैंने रेपो ब्राउज़ करने और अतिरिक्त फ़ाइलों को हटाने के लिए TortoiseSVN का उपयोग किया। फिर मैंने अपने स्थानीय फ़ोल्डर डुप्लिकेट फ़ाइलों से हटा दिए, और svn अपडेट आखिरकार सफल हुआ।
13

केवल एक विंडोज मुद्दा नहीं है। यह मैक को भी प्रभावित करता है। Mac HFS + filesystems, डिफ़ॉल्ट रूप से, केस-असंवेदनशील भी होता है, लेकिन फ़ाइल नामों को संरक्षित करने के मामले। मैंने अपनी हार्ड ड्राइव पर एक दूसरा विभाजन सेटअप किया है जो इन मुद्दों के आसपास पाने के लिए केस-संवेदी फ़ाइल नामों को करता है।
डेविड डब्ल्यू।

4

svn cleanupएक टर्मिनल में कमांड चलाएं (यदि यह ग्रहण से विफल रहता है जो मेरा मामला था):

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

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

एक्शन टीमहेड टू अपडेट विफल:

svn: E155004: '/ घर / उपयोगकर्ता / पथ / से / svn-folder' में अपूर्ण कार्य आइटम हैं; सबसे पहले 'svn cleanup' चलाएं।

एक्शन टीमक्लीनअप एक ही त्रुटि के साथ विफल हो जाता है।

समाधान जो मेरे लिए काम करता है: एक टर्मिनल में svn सफाई कमांड चलाएं

आज्ञा सफल हुई।

फिर टीम → ग्रहण में अपडेट फिर से काम किया।

नोट: मेरा SVN संस्करण 1.9.3 है।

अगर काम न हो तो क्रिस का जवाब भी देख लें svn cleanup


3

मैंने svn cleanupकंसोल के माध्यम से करने की कोशिश की है और एक त्रुटि मिली है जैसे:

svn: E720002: Can't open file '..\.svn\pristine\40\40d53d69871f4ff622a3fbb939b6a79932dc7cd4.svn-base':
The system cannot find the file specified.

इसलिए मैंने इस फाइल को मैन्युअली (खाली) बनाया और svn cleanupफिर से किया। इस बार ठीक किया गया था।


3

मुझे भी यही समस्या थी। मेरे लिए इसका कारण ईज़ीएसवीएन और (कछुआ एसवीएन या एसवीएन) के साथ संघर्ष था। मेरे पास EasySVN (जो काम नहीं कर रहा था) के साथ ऑटो अपडेट और कमिट था।

जब मैंने इसे बंद कर दिया, तो मैं सफाई, कमिटमेंट या अपडेट करने में असमर्थ था। उपरोक्त समाधानों में से किसी ने भी काम नहीं किया, लेकिन रिबूटिंग किया :)


याये जीमी, आप मेरे हीरो (इन) हैं।
ट्रोआ

2

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


2

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

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

(चेकआउट के बारे में… फिर…)

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इसके बाकी हिस्सों की जांच करने के लिए चला गया।


2

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

# 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/

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


2

मैं हाल ही में भाग गया। मेरे लिए चाल "क्लीन अप" का चयन करने के बाद, पॉपअप विकल्प संवाद में, "ब्रेक लॉक" की जांच करें, और फिर "ओके" पर क्लिक करें। यह मेरे लिए सफलतापूर्वक साफ हो गया।


1
एसवीएन में प्रति पॉपअप संवाद नहीं है; शायद आप कछुआ का उपयोग कर रहे हैं। ओपी कमांड लाइन क्लाइंट का उपयोग कर रहा है, इसलिए आपकी सलाह बहुत मददगार नहीं है।
रॉबर्ट

1

विंडोज के वास्तव में शैतानी लॉकिंग व्यवहार से सबक्लिप भ्रमित हो जाता है। अनलॉकर आपका दोस्त है। यह लॉक की गई फ़ाइलों को ढूंढ सकता है और ताले को जबरन रिलीज़ कर सकता है।


1

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

फ़ोल्डर को हटाएं आपत्तिजनक फ़ाइल (ओं) में हैं - हां, यहां तक ​​कि .svnफ़ोल्डर भी , फिर svn cleanupबहुत ऊपर / मूल फ़ोल्डर पर करें।


1

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


1

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


यह एक cmd विंडो के साथ भी काम करता है। मुझे नहीं पता कि कछुआ विफल होने पर क्यों काम करता है, लेकिन यह कभी-कभी होता है।
वॉट्सिमोटो

0

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


0

यह सभी स्थितियों में लागू नहीं हो सकता है, लेकिन जब मैंने हाल ही में इस समस्या का सामना किया तो मेरा "फिक्स" मेरे सिस्टम पर सबवर्सन पैकेज को अपग्रेड करना था। मैं 1.4.something चला रहा था, और जब मैं नवीनतम (मेरे मामले में 1.6.6) में अपग्रेड किया गया तो चेकआउट ने काम किया।

(मैंने इसे फिर से डाउनलोड करने की कोशिश की, लेकिन एक साफ निर्देशिका के लिए एक चेकआउट हमेशा एक ही स्थान पर लटका दिया गया।)


0

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


0

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

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


0

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

#>svn st
!       my_dir
!       my_dir\sub_dir

svn cleanup, svn revert, svn updateऔरsvn resolve यह सब तय करने में असफल रहे थे।

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

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

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

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

बिल्कुल ऑन-टॉपिक नहीं, लेकिन शायद मददगार अगर कोई इस पोस्ट पर आया जैसा मैंने किया।


0

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

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


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

डाउनवोट क्योंकि "svn सफाई विफल होने पर मैं चीजों को कैसे ठीक करता हूं" का जवाब "यह काम नहीं करना चाहिए"
15:16

0

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

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


0

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


0

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

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


0

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.