2010-03-21 9 views
16

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

हम का उपयोग करें: ग्रहण, TortoiseSVN, सबवर्सन

मैंने पाया somewhere कि मैं जावा फाइलों में .svn फोल्डर और पैकेज के नाम की सामग्री के बीच बेतरतीबी को रोकने के लिए कई चरणों में कर देना चाहिए:

  • पहले .svn निर्देशिकाओं को अद्यतन करने, निर्देशिका का नाम बदलने के लिए TortoiseSVN का उपयोग करें।
  • फिर, मैन्युअल रूप से निर्देशिका को मूल नाम पर पुनर्नामित करें।
  • अंततः जावास्क्रिप्ट को नए नाम पर संकुल (रिफैक्टर) का नाम बदलने के लिए ग्रहण का उपयोग करने के लिए, जावा फाइलों को अद्यतन करना।

यह मेरे लिए अच्छा लगता है, लेकिन मुझे यह जानने की जरूरत है कि वंश और इतिहास और बाकी सब कुछ अभी भी सुसंगत और अच्छी तरह से काम करेगा या नहीं।

मेरे पास उस सर्वर की कुंजी नहीं है, इसलिए मैं जल्दी से बैकअप चीजें नहीं करता हूं और एक या दो चीजों को आजमाता हूं। मैं ऐसा करने के लिए एक अच्छा कारण नहीं आना चाहता हूं, या ऐसा करने का एक तरीका जो काम करता है।

का नाम बदलने के परीक्षण के लिए आपकी मदद के लिए धन्यवाद,

एम Joanis


पैकेज

प्रक्रिया:

  1. एक नए पैकेज com.oldname.test बनाएं .renametest.subpackage। कि RenameTest0 ठीक चलाता

    class RenameTest1 { 
        public RenameTest1() { 
         showMessage(); 
         RenameTest0.showMessage(); 
        } 
        public static void showMessage() { 
         System.out.println("RenameTest1!"); 
        } 
    }
  2. टेस्ट:

  3. renametest के तहत एक नया वर्ग जोड़ें RenameTest0.java कहा जाता है और युक्त

    class RenameTest0 { 
        public RenameTest0() { 
         showMessage(); 
         new RenameTest1(); 
        } 
        public static void showMessage() { 
         System.out.println("RenameTest0!"); 
        } 
        public static void main(String[] args) { 
         new RenameTest0(); 
        } 
    }
  4. युक्त renametest.subpackage के तहत एक नया वर्ग जोड़ें।

  5. प्रतिबद्ध।
  6. दोनों कक्षाओं के संदेशों को बदलें।
  7. प्रतिबद्ध।
  8. फिर, एक वर्ग का संदेश बदलें और प्रतिबद्ध करें (केवल कुछ इतिहास बनाएं)।
  9. टेस्टरेनेम में पैकेज नाम बदलने के लिए ऊपर प्रस्तावित प्रक्रिया (मूल संदेश में तीन चरणों) लागू करें।
  10. प्रतिबद्ध।
  11. टेस्ट रन।
  12. संदेशों को दोबारा संशोधित करें और परीक्षण करें।
  13. प्रतिबद्ध।
  14. संस्करण पर वापस रोल करने का प्रयास करें जब दोनों संदेशों को पहली बार बदल दिया गया हो।
  15. अगर सब कुछ इस बिंदु पर ठीक काम करता है, तो यह अच्छा लगता है, नहीं? परीक्षण के

परिणाम:

  • चरण 9 पर ध्यान दें: किसी और उलटे क्रम में यह करने के लिए (। ग्रहण तो नाम बदलने का नाम बदलने के TortoiseSVN), यह जटिल हो रही किया गया था, के रूप में TSVN एक नया बनाने था फ़ोल्डर/पैकेज और हटाए जाने के लिए पुराने को चिह्नित करता है ... तो आप ग्रहण के लिए नाम बदल नहीं सकते हैं जब तक कि आप खोए गए एसएसएन फ़ोल्डर्स इत्यादि को रोकने के लिए कहीं और पुराना पैकेज नहीं डालते हैं। अच्छा नहीं लग रहा था इस विधि के साथ आगे जाने का विचार। (अपने आप को ध्यान दें: रिकर्सिव पैकेज नामकरण के लिए चेकबॉक्स को चेक करना न भूलें!)
  • चरण 14 पर नोट: कार्यरत! हम पिछले संस्करण देख सकते हैं; हमें बस इतना करना है कि प्रतिलिपि/चाल को तोड़ना न पड़े और यह ठीक है। एक बार नाम बदलने से पहले एक संस्करण में वापस लौटने के बाद, पैकेज नाम अच्छे नाम पर वापस नहीं आते हैं, हालांकि, शायद यह फिर से इसे पुन: सक्रिय करेगा।
  • अंत नोट: मुझे आश्चर्यजनक क्रम में महत्वपूर्ण कदम उठाने के लिए आश्चर्यचकित था। इस पहले पैकेज के बीच में यह सही करने के लिए प्रयास करें, मुझे कुछ टीएसवीएन और मैन्युअल संशोधनों को वापस लेना पड़ा, इस प्रक्रिया के सटीक परिणामों की दोहराने योग्य प्रकृति पर थोड़ा सा संदेह डालना पड़ा। मुझे इसकी वैधता की पुष्टि करने के लिए दूसरा परीक्षण करना होगा। समेकित करने के लिए: यह अच्छा लग रहा है, लेकिन आगे परीक्षण की आवश्यकता है।
+5

ऐसा करने का एक अच्छा कारण यह नहीं होगा कि यह किसी भी लाभ के लिए काम की अच्छी मात्रा (परीक्षण सहित) होगा। अगर आपको लगता है कि कोई com.oldname स्पेस में पुस्तकालयों का उत्पादन शुरू करने जा रहा है जो आपके साथ टकराएगा, तो यह इसके लायक हो सकता है, लेकिन डोमेन उपसर्गों का पूरा विचार विशिष्टता की गारंटी देना था, न कि मार्केटिंग लोक को संतुष्ट करना। – msw

+0

मुझे यह स्वीकार करना होगा कि यह एक बहुत अच्छा बिंदु है ... – Joanis

+0

@ डॉन किर्बी और @ करसुसेल: मैं आज या कल एक परीक्षा चलाने की कोशिश करूंगा और इसके बारे में एक प्रतिक्रिया दूंगा। – Joanis

उत्तर

8

के अनुसार यह आपकी समस्याओं का समाधान कर सकता है, शायद यह आपकी सटीक आवश्यकताओं के लिए व्यावहारिक नहीं है लेकिन TortoiseSVN के नामों के बारे में एक आसान सुविधा है। आप यह कर सकते हैं:

  1. सामान का नाम बदलने के लिए अपनी आईडीई की रीफैक्टरिंग सुविधा का उपयोग करें।
  2. TortoiseSVN से "संशोधनों के लिए जांचें" संवाद लॉन्च करें।
  3. प्रत्येक नामित आइटम के लिए, आपको दो प्रविष्टियां दिखाई देगी: एक अनुपलब्ध "स्रोत.जावा" आइटम और एक विचलित "target.java" आइटम। दोनों को हाइलाइट करें और संदर्भ मेनू से "मरम्मत स्थान" चुनें।

Repair moves/renames

+0

यह लिंक – naumcho

+0

टूटा हुआ है, लेकिन यदि आपके पास उपclipse की तरह एक ग्रहण एसवीएन प्लगइन स्थापित है, तो यह काम नहीं करेगा, है ना? – User

0

हाँ, यह काम करेगा। आप svn के कमांड लाइन संस्करण को स्थापित कर सकते हैं और एक बैच फ़ाइल लिख सकते हैं जो svn सामान करेगा। ग्रहण सामग्री को स्वचालित करना थोड़ा और काम होगा, और शायद इसके लायक नहीं है जब तक कि आप पहले ग्रहण एपीआई से परिचित नहीं हैं।

यह सुनिश्चित करने के लिए कि आप सभी चरणों को सही तरीके से कर रहे हैं, सब कुछ करने से पहले इसे एक पैकेज के साथ परीक्षण करें।

2

क्या आप वाकई इतिहास को काम नहीं कर रहे हैं यदि आप ग्रहण में शामिल रिफैक्टरिंग विधि का उपयोग कर रहे हैं?

नेटनियंस के साथ मैं नियमित रूप से पैकेज नाम बदलता हूं और अंतर्निहित 'svn प्लगइन' चुपचाप नई निर्देशिका में सामग्री (जो इतिहास बचाता है) को स्थानांतरित करता है (उसके बाद सामान्य रिफैक्टरिंग होगा)।

तो: क्या आपने इसे ग्रहण के भीतर से आज़माया है यदि इतिहास को उपवर्तन प्लगइन के साथ रखा गया हो? (में जैसे एक ताजा चेक-आउट की प्रतिलिपि विफलता से बचने के लिए)

कम से कम आप NetBeans इस्तेमाल कर सकते हैं यह एक बार का काम करने के लिए ...

+0

+1: यहां तक ​​कि प्रश्न ग्रहण के लिए भी था, इससे मुझे बहुत मदद मिलती है। netbeans प्लगइन मेरे लिए ठीक काम करता है।(बस प्लगइन के साथ प्रतिनिधि को अपडेट करने के लिए सुर करें और रिफैक्टर करने से पहले किसी अन्य एसवीएन क्लाइंट के साथ नहीं) – Loda

0

आप कर सकते हैं ऐसा करते हैं, और यह है कि मुश्किल नहीं है - एक स्वच्छ एसवीएन इतिहास प्राप्त करने के लिए आपकी सबसे अच्छी शर्त इसे 2 चरणों में करना है (एक प्रतिबद्ध बन सकता है) - हालांकि अच्छे परिणामों के लिए मैं सीएलआई क्लाइंट का उपयोग करने की सलाह देता हूं।

  1. उपयोग SVN mv ग्रहण में फ़ोल्डरों/संकुल
  2. जाओ ले जाते हैं, या CLI से ग्रेप का उपयोग फ़ाइलों में संकुल ठीक करने के लिए नए नाम से मिलान करने

तो फिर तुम प्रतिबद्ध कर सकते हैं करने के लिए एक परिवर्तन सेट के रूप में, और फ़ाइल स्तर पर इतिहास मेल खाना चाहिए।

आप Maven या एक पैकेजिंग उपकरण का उपयोग कर रहे हैं, सुझाव है कि आप कुछ इस तरह करने से पहले एक रिलीज चलाने - यह भी मामले में इस से ठीक पहले एक टैग काटने लायक है आप पुरानी संरचना

0

मुझे पता चला कि Subclipse प्लगइन जब एक वर्ग है कि (अभी तक यानी स्रोत नियंत्रण में नहीं) एक नए पैकेज के लिए ले जाया गया है प्रतिबद्ध होते हैं और त्रुटि संदेश देता है "पहले से ही संस्करण नियंत्रण में है" इस पैकेज का अभिभावक भी नया है।

जब ऐसा होता है, तो मैं TortoiseSVN का उपयोग कर परिवर्तन कर सकता हूं। इसके बाद मुझे केवल ग्रहण में परियोजना को ताज़ा करने की आवश्यकता है।

कक्षा को एक नए पैकेज में ले जाने के बाद जिसका अभिभावक पहले से ही स्रोत नियंत्रण में है, उपclip समस्याओं के बिना इस परिवर्तन को कर सकता है।

0
इसके बजाय संकुल आप ऐसा कर सकता है नाम बदलने के

:

  1. अपनी परियोजना में नए पैकेज इकाई बनाते हैं। एक बार अपनी परियोजना किया कुछ इस तरह दिखना चाहिए:

     com - 
          |- myOLDcompname - 
          |    |- feature1 - 
          |       |- classA.java 
          |       |- classB.java 
          |- myNEWcompname - 
              |- feature1 
    
  2. संस्करण नियंत्रण में नए फ़ोल्डर जोड़ें ताकि SVN ट्रैक कर सकते हैं उन्हें

  3. नए लोगों के लिए पुराने संकुल से अपने जावा वर्गों के लिए कदम। ग्रहण के अनुसार सभी कक्षाओं के आयात और पैकेज घोषणाओं को अद्यतन करना चाहिए। सबसे महत्वपूर्ण बात यह है कि पुराने और नए पैकेज वीसीएस के तहत हैं, इस चरण को कक्षाओं का इतिहास रखना चाहिए।
  4. पुराने फ़ोल्डरों को हटाए जाने पर
  5. प्रतिबद्ध!
संबंधित मुद्दे