सबवर्सन ऑब्लिटरेट फीचर

Question

मैं बस एक आसान तरीका (बाहरी रूप से, सुझाए गए तरीके का उपयोग करके, लेकिन स्वचालित) में निरपेक्ष कार्यक्षमता को लागू करने के लिए एक शेल स्क्रिप्ट लिखने की सोच रहा था।

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

ग्राहक

1. svn list -R > file-list पर।
2. फ़ाइल फ़ाइलों को सूची "फाइल-टू-डिलीट" बनाने के लिए grep जैसे कई तरीकों से फ़िल्टर करें, grep XXX file-list>>files-to-delete के सेट की तरह कुछ।
3. एसपीपी का उपयोग कर सर्वर पर files-to-delete स्थानांतरण।

सर्वर

1. भंडार svnadmin dump /path/to/repos > repos-dumpfile डंप पर, यह एक बैकअप भी रूप में रखा जा सकता है।
2. , "फ़ाइलें करने के लिए हटाना" में डंप फ़ाइल, प्रत्येक शब्द के लिए फ़िल्टर करें: cat repos-dumpfile | svndumpfilter exclude $file > new-dumpfile
3. एक नया भंडार बना सकते हैं और यह svnadmin create new-name; svnadmin load new-name < new-dumpfile

इस काम करेगा नई फ़ाइल लोड? यह कैसे असफल हो सकता है? कोई अन्य विचार?

Answer 1

हां, वह स्क्रिप्ट काम करेगी। लेकिन आम तौर पर आप कई फाइलों को खत्म नहीं करते हैं। आमतौर पर विलुप्त होने की आवश्यकता होती है यदि आप गलती से गोपनीय जानकारी करते हैं।

क्या आप वाकई इतनी सारी फाइलों के लिए निरक्षर का उपयोग करना चाहते हैं?

Answer 2

मुझे लगता है कि cat new-dumpfile | svndumpfilter exclude $file > new-dumpfile एक खतरनाक उदाहरण है। नई डंपफाइल पूरी तरह संसाधित नहीं की जाएगी और इसकी सामग्री शायद खो जाएगी, नहीं?

नीचे दी गई टिप्पणियों से: नया-डंपफाइल निश्चित रूप से खो जाएगा, क्योंकि खोल कमांड शुरू करने से पहले भी गोलाकार (शून्य लंबाई तक छोटा हो जाएगा)।

Answer 3

विभिन्न संशोधनों में एक ही पथ वाली फ़ाइलों के बारे में क्या? उदाहरण के लिए, यदि आप /trunk/foo प्रतिबद्ध करते हैं, तो इसे /trunk/bar पर पुनर्नामित करें, फिर /trunk/foo पर कुछ और करें जिसे आप निरस्त करना चाहते हैं। आप अब /trunk/bar के इतिहास को खोना नहीं चाहते हैं। शायद svndumpfilterpeg revisions का समर्थन करता है?

Answer 4

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

हालांकि, svn list को एक संशोधन तर्क दिया जा सकता है। मुझे यकीन नहीं था कि जब बड़ी फाइलों की जांच की गई थी, लेकिन मुझे पता था कि यह संशोधन 2000 के कुछ समय बाद था। मेरे पास फ़ाइल नामों की एक सूची भी थी।तो मैं अपने files-to-delete उत्पन्न करने के लिए एक सरल पाश और uniq प्रयोग किया है:

cd $working_copy 
for rev in {2000..2437}; do 
    svn ls -R -r$rev | grep -f ~/tmp/big-file-names >> ~/tmp/file-paths; 
done 
cat ~/tmp/file-paths | sort | uniq > ~/tmp/files-to-delete 
cd ~/tmp 
# You should inspect "files-to-delete" to see if it looks reasonable! 
cat dumpfile | svndumpfilter exclude `cat files-to-delete` > dumpfile.new