2010-11-07 10 views
6

मैं एक ऐसी कंपनी में काम करता हूं जहां हम बहुत से छोटे ग्राहक-विशिष्ट अनुप्रयोग बनाते हैं। हम कुछ डेवलपर्स हैं लेकिन अधिकांश समय प्रति परियोजना केवल एक डेवलपर है।क्या DVCS (Mercurial) मेरे लिए नहीं है?

Customer1 
    ProjectX 
     App 
     Tests 
    ProjectY 
     App 
     Tests 
Customer2 
    Project2 
Products 
    Product1 
Common 

आज सब कुछ एक ही भंडार में संग्रहीत किया जाता है।

प्रक्रिया सरल है।

  1. एक डेवलपर एक ग्राहक के लिए एक नई परियोजना पर ले जाता है
  2. नई परियोजना
  3. में
  4. कोड परियोजना के लिए एक नया फ़ोल्डर बनाएँ रखरखाव के लिए अद्यतन में एक अन्य परियोजना में कुछ रखरखाव करते हैं
  5. चेक प्रोजेक्ट
  6. नई परियोजना
  7. नई परियोजना में जांचें
  8. ग्राहक को

कोई टैगिंग और न ही शाखाकरण है। पहले के संस्करणों को तारीख के आधार पर चेक आउट किया जाता है।

इस प्रक्रिया को कई वर्षों के लिए अच्छी तरह से सेवा की है लेकिन वहाँ वर्तमान उपकरण (सीवीएस)

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

मैंने कुछ समय के लिए निजी तौर पर Mercurial का उपयोग किया है और इसे सभी डेवलपर्स में विस्तारित करना चाहते हैं।

मुझे यह सब गलत हो सकता है लेकिन कुछ ऐसी चीजें हैं जिन्हें मैं समझ नहीं पा रहा हूं कि हमारे संगठन में कैसे कार्यान्वित किया जाए।

सीवीएस प्रतिबद्धता केवल वर्तमान फ़ोल्डर हैं लेकिन Mercurial में वे भंडार चौड़े हैं। हमारे मामले में इसका मतलब है कि एक फ़ोल्डर में रखरखाव कार्य करने से दूसरे फ़ोल्डर में अभी तक अधूरा सामान भी प्रतिबद्ध होगा। (मैं हम बदली हुई फ़ोल्डर में hg ci ./** कर सकता है ग्रहण लेकिन मर्ज की अनुमति नहीं है, कम से कम है कि क्या प्रलेखन कहते हैं If you are committing the result of a merge, do not provide any filenames or -I/-X filters. है)

मर्क्युरियल में आम बात परियोजना प्रति एक भंडार है। परियोजना प्रति

एक भंडार हमारे लिए ठीक है, लेकिन यह जैसे कुछ अन्य मुद्दों बनाता है:

कैसे केंद्रीय सर्वर पर कई खजाने का प्रबंधन करने के?
यदि कोई डेवलपर एक नई परियोजना बनाता है तो उसे अंततः अपने परिवर्तनों को धक्का देना पड़ता है। बस कर

hg push http://localhost:8000/Customer1/NewProject

एक बदसूरत ढेर डंप के साथ एचजी-वेबसर्वर दुर्घटनाओं और ग्राहक लटका हुआ है।

तरह से मैं समझता हूँ कि यह है कि डेवलपर एक विन्यास फाइल करने के लिए नए डेटा संग्रह स्थान जुड़ और पुनः आरंभ hgweb

विकल्प SSH हैं या साझा (उपयोग करने के लिए है करने के लिए सर्वर खोल करने के लिए उपयोग की जरूरत है कर रहे हैं वहाँ का उपयोग कर लाभ एक फाइल शेयर करने के बजाय SSH?)

cd Customer\NewProject 
hg init 
hg clone --noupdate --pull . //mercurialshare\Customer\Project 
echo "[paths]" >.hg\hgrc 
echo "default=//mercurialshare\Customer\Project" >>.hg\hgrc 

hg push 

काम करता है, लेकिन कुछ डेवलपर्स

सभी डेवलपर्स सभी परियोजनाओं की आवश्यकता के लिए जटिल करने के लिए एक सा है।
(नहीं वास्तव में सभी लेकिन कई परियोजनाओं से जुड़े हुए हैं तो वे उपस्थित रहने की जरूरत है और यह सबसे आसान है बस सभी के लिए)

कई मौजूदा परियोजनाओं और नए लोगों को साप्ताहिक जोड़ा हम एक में सभी परियोजनाओं को खींचने के लिए कोई तरीका होना चाहिए के साथ

जाओ और नए क्लोन भी करें।

मैं सोच रहा था कि subrepos "वैश्विक" पुल का समाधान कर सकता है, लेकिन दस्तावेज में निम्नलिखित लाइन देखने लायक दृश्य

"जब हम प्रतिबद्ध, मर्क्युरियल पूरे के राज्य के एक सुसंगत स्नैपशॉट बनाने के लिए प्रयास करता है प्रोजेक्ट और इसके सबरेप। यह पहले सभी संशोधित उपरोक्तों में प्रतिबद्ध करने और फिर सभी सब्रेप्स की स्थिति रिकॉर्ड करने का प्रयास करता है। "

वैश्विक प्रतिबद्धताओं की एकल रिपोजिटरी समस्या पर वापस जाएं।

(hg ci .hgsub .hgsubstate <subrepo> के कुछ वेरिएंट की कोशिश की लेकिन .hgsubstate केवल पूर्ण प्रतिबद्ध पर अद्यतन कर रहे हैं। अन्य उपयोगकर्ताओं को प्रोजेक्ट फ़ोल्डर में स्पष्ट hg pull --update बिना परियोजना परिवर्तन नहीं देखेंगे)

मेरे वर्तमान सोच एक है रूट में बैच फ़ाइल जो सभी परियोजनाओं को खींचती है

हमारे संगठन में Mercurial का उपयोग करने के तरीके पर कोई अन्य विचार?

संपादित

उत्तर के लिए धन्यवाद। मैं वर्तमान में मूल्यांकन कर रहा हूं कि प्रति परियोजना एक प्रतिस्थापन हमारे लिए कैसे काम करेगा। मैंने शीर्ष स्तर

FOR /F %%x IN (repolist.txt) DO (
    If EXIST .\%%x\.hg (
     ECHO Pull %%x 
     hg pull --update --repository .\%%x 
    ) ELSE (
     ECHO Clone %%x 
     mkdir .\%%x 
     hg clone --pull %1\%%x .\%%x 
    ) 
) 
+0

["सिर्फ इसलिए कि आप एक वितरित तरीके से एक डीवीसीएस का उपयोग कर सकते हैं इसका मतलब यह नहीं है कि आपको चाहिए।"] (Http://stackoverflow.com/q/3854611) –

उत्तर

8

पर एक बैच फ़ाइल डाली है यह कहने का आपका अधिकार है कि Mercurial को एक प्रोजेक्ट प्रति रेपो के लिए डिज़ाइन किया गया है। जब आप इस तरह काम करते हैं तो यह भी बहुत अच्छा है क्योंकि विभिन्न परियोजनाओं का इतिहास अलग रखा जाता है।

एक डीवीसीएस रेपो में कई परियोजनाएं करने का प्रयास करने से दर्द होता है।

व्यक्तिगत रूप से मैं HTTP के बजाय एसएसएच के माध्यम से परियोजनाओं की सेवा करना पसंद करता हूं। एक कारण यह है कि ...

# hg init blah 
# hg clone blah ssh://server/blah 

यदि आप HTTP के माध्यम से सेवा कर रहे हैं तो यह काम नहीं करता है (जैसा कि आपने पाया है)।मुझे आश्चर्य है कि यह एक कठिन दुर्घटना का कारण बनता है: -/

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

वास्तव में आप जो भी बाद में नहीं हैं।

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

अन्यथा स्क्रिप्ट विचार शायद सबसे आसान है।