2010-08-19 16 views
15

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

  • src
  • WebContent
  • निर्माण
  • जिले
  • build.xml
  • .project
  • .classpath
  • । सेटिंग्स/

निर्माण निर्देशिका को स्पष्ट रूप से चेक नहीं किया जाना चाहिए। दूसरे के बारे में क्या? मैं सभी का अनुमान लगा रहा हूं। फ़ाइलों को या तो चेक नहीं किया जाना चाहिए। क्या कोई इसे सत्यापित कर सकता है? यह dist निर्देशिका और .settings निर्देशिका क्या है?

ग्रहण सर्वर जानकारी (टोमकैट) कहां रखता है? मैं इसे या तो जांचना नहीं चाहता हूं।

संपादित करें:

मैं शुरू में निश्चित रूप से निर्माण निर्देशिका को छोड़कर ऊपर के सभी में जाँच की। जब मैंने ग्रहण के अंदर से परियोजना की जांच की तो उसने मुझे एक नई परियोजना बनाने के लिए संकेत नहीं दिया क्योंकि प्रोजेक्ट वहां है लेकिन ग्रहण एक जावाईई प्रोजेक्ट या गतिशील वेब प्रोजेक्ट की बजाय कुछ बना रहा था। क्या किसी और ने इस व्यवहार में भाग लिया?

** संपादित करें 2 **

इसे मिला!

  • .project
  • .settings/
  • .classpath

एक बार इन 3 नई परियोजना जादूगर निकाल दिए जाते हैं उम्मीद काम करता है के रूप में है और सब कुछ - मैं निम्नलिखित में जाँच नहीं करना चाहिए पता चला है ठीक है।

उत्तर

13

यदि आप .classpath/.project/.settings में चेक इन करते हैं तो आप अपनी परियोजना ग्रहण-विशिष्ट बनाते हैं। Netbeans या IntelliJ के साथ काम करने वाले डेवलपर्स के बारे में क्या? आईएमओ आपके प्रोजेक्ट आईडीई-स्वतंत्र और स्थापित करने में आसान रखने के लिए क्लीनर है।

मैं आमतौर पर एक मेवेन बिल्ड के लिए जाता हूं। pom.xml सभी आवश्यक निर्भरताओं को निर्दिष्ट करता है और mvn eclipse:eclipse आपके लिए .classpath/.project फ़ाइलों को उत्पन्न करता है।

.settings निर्देशिका में स्थानीय सेटिंग्स (जैसे जावा संस्करण आप उपयोग करना चाहते हैं) शामिल हैं। आईएमओ इसे जांचने के लिए उपयोगी नहीं है। आप मैवेन 2 पोम के माध्यम से जावा संस्करण अनुपालन को लागू कर सकते हैं।

अंत में, अपनी अगली परियोजना के लिए, मेरे Protip svn-ignore फाइल या निर्देशिका के लिए आप नहीं SVN में से पहले अपने पहले प्रतिबद्ध चाहते हैं। एक Maven2 सेटअप में .settings.classpath.projecttarget (Maven2 की डिफ़ॉल्ट आउटपुट निर्देशिका) और किसी भी अन्य जेनरेट की गई सामग्री (लॉग फ़ाइलें, gfembed निर्देशिका, आदि) होगा। आपके मामले में आप target के बजाय build और dist को अनदेखा कर देंगे।

आप svn-ignoreRIGHT_MOUSE->Team->'Add to svn:ignore' (मैं उपclipse प्लगइन का उपयोग कर सकते हैं) के साथ फाइलें या निर्देशिका कर सकते हैं। अनदेखा निर्देश माता-पिता निर्देशिका पर svn-properties के रूप में संग्रहीत हैं। निर्देशिका पर गुण RIGHT_MOUSE->Team->Show properties द्वारा देखे जा सकते हैं। आप मूल्य फ़ील्ड पर क्लिक करके सीधे गुणों को भी संपादित कर सकते हैं। सुनिश्चित करें कि प्रत्येक संपत्ति के बाद लाइन का अंत हो।

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

+0

धन्यवाद कि आईडीई विशिष्ट के बारे में एक अच्छा बिंदु है फ़ाइलों और svn का उपयोग करने के लिए यह एक अच्छा विचार भी अनदेखा करें। – user220201

+0

जबकि .settings की सामग्री ग्रहण-विशिष्ट है, इसका मतलब यह नहीं है कि उन्हें आपकी टीम के अन्य सदस्यों के साथ साझा करने की आवश्यकता नहीं है। विशेष रूप से, आप अपनी परियोजना के लिए अपनी जेडीटी चेतावनी प्राथमिकताओं को साझा करना चाह सकते हैं। उन्हें उत्पन्न करके उन्हें साझा करना वास्तविक दर्द होगा। –

+0

अच्छा बिंदु। मैं कभी-कभी आईडीई से निर्यात करके और फ़ाइलों को साझा करके ऐसी सेटिंग्स साझा करता हूं। उदाहरण के लिए ग्रहण स्वरूपण और कोड टेम्पलेट नियमों को निर्यात करने की अनुमति देता है। एक और उदाहरण चेकस्टाइल सेटिंग्स है। ये सभी सेटिंग्स आमतौर पर कंपनी-व्यापी नीतियां होती हैं, इसलिए अक्सर उन्हें कॉन्फ़्लुएंशन विकी पर पाता है, प्रत्येक प्रोजेक्ट में चेक नहीं किया जाता है। –

0

मैं प्रोजेक्ट, .settings /, dist, और build को छोड़ दूंगा।

यदि आप हार्डकोडेड पथों के बजाय चर का उपयोग करते हैं तो क्लासपाथ छोड़ा जा सकता है। यह उपयोगी है इसलिए जब भी आप परियोजना की जांच करेंगे तो आपको अपने क्लासपाथ को पुनर्निर्माण करने की आवश्यकता नहीं है।

11

हमारे मामले में, हमने आपके द्वारा सूची में उल्लिखित सभी में चेक किया है, .settings /।

.classpath और .project के साथ चेक-इन किया गया, उपयोगकर्ता तुरंत परियोजना को देख सकते हैं और ग्रहण को नए कंप्यूटर पर फायर कर सकते हैं और बस उस पर काम करना शुरू कर सकते हैं; वैकल्पिक रूप से प्रोजेक्ट को कॉन्फ़िगर करने और सभी जार निर्भरताओं में दर्दनाक रूप से जोड़ने का विकल्प (यदि आप चींटी का उपयोग करते हैं)। कई खुली स्रोत परियोजनाएं यह करती हैं।

this पढ़ें, इसके बारे में सोचने के लिए कुछ वाकई अच्छे अंक हैं।

+0

ब्लॉग पोस्ट के लिए मृत लिंक, नया यूआरएल है: http://lousycoder.blogspot.com/2008/09/arguments-against-checking-in-your.html – David

2

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