तोड़फोड़ की स्थिति का प्रतीक "~" क्या है?

Question

जब मैं एक करता हूँ मुझे एक तिल प्रतीक मिल रहा है svn status।

यहाँ XCode में संपादन के बाद परियोजना का आउटपुट है।

svn status
M      build/Currency_Converter.build/Currency_Converter.pbxindex/imports.pbxbtree
M      build/Currency_Converter.build/Currency_Converter.pbxindex/pbxindex.header
M      build/Currency_Converter.build/Currency_Converter.pbxindex/symbols0.pbxsymbols
~      build/Currency_Converter.build/Currency_Converter.pbxindex/strings.pbxstrings
M      main.m
//more changed files

किसी भी विचार का क्या मतलब है? यह गूगल या svn धोखा शीट्स में से किसी पर खोजने के लिए प्रतीत नहीं कर सकते।

दिलचस्प है, मैंने केवल main.m को संपादित किया है, लेकिन बहुत सारी संशोधित फाइलें हैं। डन्नो ऐसा क्यों होगा। किसी को भी SVN और XCode के साथ काम करने के लिए कोई सुझाव है? क्या मुझे केवल संस्करण नियंत्रण के तहत अपनी स्रोत फ़ाइलें डालनी चाहिए?

संपादित करें: - एक फ़ाइल के कारण जो पहले से ही संस्करण नियंत्रण के तहत दूसरे प्रकार की फ़ाइल द्वारा प्रतिस्थापित की जा रही थी। इस स्थिति में, strings.pbxstrings एक फ़ाइल हुआ करती थी और अब एक निर्देशिका बन गई है। कहानी का नैतिक संस्करण नियंत्रण में आपके बिल्ड फ़ोल्डर को नहीं रखा गया है।

Comments

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

— चाड बर्च

Answer 1

SVN बुक का कहना है:

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

तो शायद यह मूल रूप से एक एकल फ़ाइल थी, लेकिन आपने इसे निर्देशिका में बदल दिया, या उन पंक्तियों के साथ कुछ?

Comments

ऐसा लगता है कि आप सही हैं। यह एक .svn फ़ाइल के बिना अब एक निर्देशिका है। कैसे तय करने के बारे में कोई विचार? क्या मुझे इसे तोड़फोड़ से हटाने और इसे फिर से जोड़ने की आवश्यकता है?

— ०४

किसी भी मौका आप इसे ठीक करने के लिए एक रास्ता मिल गया?

— फिल पाफर्ड

सबसे अच्छा समाधान नई वस्तु (आपके मामले में, निर्देशिका) का नाम बदलना है; "svn remove" ऑब्जेक्ट को रिपॉजिटरी से जो टकराव का कारण बन रहा है (शायद एक फ़ाइल जिसे आपने हटा दिया है), कमिट करें, फिर नई ऑब्जेक्ट का नाम बदलें और रिपॉजिटरी में "svn add" करें। फिर से कमिट करें। आपके पास 3 संशोधनों का एक अनुक्रम होगा जहां पुरानी वस्तु मौजूद थी, हटा दी गई थी, और नई वस्तु को क्रमशः जोड़ा गया था।

— ब्रायन लैसी

यदि इस थ्रेड को पढ़ने वाले किसी भी व्यक्ति के पास एक ही समस्या है: यह मेरे लिए हुआ और '~' स्थिति का कारण यह था कि मेरे पास रिपॉजिटरी में कुछ प्रतीकात्मक लिंक थे, जिन्हें 'sed -i' ऑपरेशन द्वारा मानक फाइलों द्वारा अधिलेखित कर दिया गया था । मैंने प्रतीकात्मक लिंक पुनः बनाए और '~' चला गया।

— जेबी

@JamieBullock आज भी उसी वजह से मेरे साथ वही हुआ। मैंने इस कमांड की कोशिश की, इससे पहले कि मैं यह भी जानता था कि समस्या क्या थी: svn status | grep ^~ | grep -o [^[:space:]]\*\$ | xargs svn revertजो सभी सहूलियतों को बहाल करने में सक्षम थी।

— पॉल

Answer 2

यहाँ मैंने क्या किया है:

यदि फ़ोल्डर परीक्षण है

1. mv टेस्ट Test1
2. svn निकालें टेस्ट
3. mv टेस्ट 1 टेस्ट

Comments

यह मेरे लिए तब तक काम करता था जब तक मैं इसे हटाने और जोड़ने के बीच में प्रतिबद्ध था। 1. mv टेस्ट Test1 2. svn remove Test 3. svn प्रतिबद्ध -m "हटाए गए टेस्ट" 4. mv Test1 टेस्ट 5. svn ऐड टेस्ट 6. svn कमिट -m "

— Add

@Sancelot द्वारा उत्तर ज्यादा बेहतर है; उपयोग करने पर आपको नाम बदलने की कोई आवश्यकता नहीं है svn delete --keep-local fileName।

— डॉनसॉन्ग

Answer 3

से

svn help status

'~' विभिन्न प्रकार के कुछ आइटम द्वारा बाधित संस्करण

मैंने केवल इसे देखा है जहां फ़ाइल अनुमतियाँ बदल गई थीं और svn के पास उस पर कोई निष्पादन नहीं था जो मैं निंदनीय था।

उम्मीद है की यह मदद करेगा।

Answer 4

इसे ठीक करने का सबसे आसान तरीका बैकअप है, फिर उस फ़ोल्डर या फ़ाइल को हटा दें जिसकी यह स्थिति है और फिर "svn up" करें: यह जरूरी नहीं कि फ़ाइल द्वारा रिलेट किया गया कोई फ़ोल्डर हो, यह सिर्फ हो सकता है। ssv फ़ोल्डर गायब या दूषित है। ।

Answer 5

svn delete --keep-local x
svn commit -m "del x"
svn add x
svn commit -m "blah"

Comments

नाम बदलने की जरूरत नहीं। आपने सबसे अच्छा जवाब दिया।

— डॉनसॉन्ग

सबसे बढ़िया उत्तर! यह समस्या को हल करता है। मेरे मामले में यह एक नियमित फ़ाइल के रूप में किया गया एक नरम लिंक था।

Answer 6

ऐसा तब हो सकता है जब आप एक फ़ोल्डर में .svn फ़ोल्डर को हटाते हैं (उदाहरण के लिए जब आप किसी निर्देशिका को निकालते हैं, और फिर आप उसी निर्देशिका को फिर से बनाते हैं), या जब आप किसी निर्देशिका को प्रतीकात्मक लिंक या उसी नाम से एक फ़ाइल से प्रतिस्थापित करते हैं। ।

मान लें कि यह एक फ़ोल्डर है जिसे फ़ोल्डर कहा जाता है, आप इसे मूल फ़ोल्डर में निम्न आदेश जारी करके ठीक कर सकते हैं:

$ find a-folder -type d -name '.svn' -print0 | xargs -0 rm -Rf
$ svn up --force .
svn: Directory 'logs/.svn' containing working copy admin area is missing
$ svn up --force .
E    a-folder
...
Updated to revision n.

और फिर यह बदलावों को फिर से जोड़ने / हटाने और फिर से लागू करने की बात है

Answer 7

इसी तरह का मुद्दा था, एसवीएन एक लॉक के बारे में शिकायत कर रहा था। यहाँ हमने क्या किया है:

• फाइलों का बैकअप लिया
• Rm -r (linux) के साथ प्रश्न में निर्देशिका को हटा दिया गया
• रैन svn सफाई निर्देशिका पर
• रॉन svn - निर्देशिका पर लागू करें

Answer 8

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

mv foo foo-bak
svn up foo
svn revert foo

# just for good measure. Foo should not show up in the two following commands.
ls | grep foo
svn st | grep foo

mv foo-bak foo
svn add foo

Answer 9

यह विंडोज के तहत प्रतीकात्मक लिंक की बात भी हो सकती है। जब आप एसवीएन में प्रतीकात्मक लिंक करते हैं और फिर इसे विंडोज के तहत देखते हैं, तो लिंक नियमित फाइलों में बदल जाते हैं और इसे ~ के रूप में भी रिपोर्ट किया जाता है।

Comments

तो आप इसे कैसे ठीक करते हैं?

Answer 10

मैं अक्सर (जैसे।) जूमला के तहत मॉड्यूल को अपग्रेड करते समय ऐसा करता था !, वर्डप्रेस या ड्रुपल। कभी-कभी .svn निर्देशिका को अपग्रेड प्रक्रिया द्वारा हटा दिया जाता है।

# rename updated directory
mv foo foo.new

# restore the old directory
svn up foo

# merge / update the old directory with new items
# notice that the above command will preserve the obsolete files
# so you should do a diff -r in order to remove them
cp -r foo.new/* foo

# Add files commit, etc
svn add foo/*
svn delete foo/xx
svn commit -m "updated module"

Answer 11

~ versioned item obstructed by some item of a different kind
    Second column: Modifications of a file's or directory's properties