क्या किसी भी संस्करण नियंत्रण प्रणाली में "लगातार स्थानीय परिवर्तन" सुविधा है?

Question

यह सवाल Git के साथ चारों ओर खेलने के दौरान घटित हुआ, लेकिन मैं सामान्य स्थिति के लिए कहेंगे ...

मैं सिर्फ एक सुविधा है जो संस्करण नियंत्रण के लिए अच्छा हो सकता है के बारे में सोचा है, लेकिन मैं अगर नहीं जानता कि यह मौजूद है या इसे क्या कहा जाता है। मैं इसे लगातार स्थानीय परिवर्तनों को कॉल करना चाहता हूं।

कहें कि मेरे पास svn में एक कॉन्फ़िगरेशन फ़ाइल है, जिसमें बहुत उपयोगी गैर-पुन: प्रयोज्य सामान हैं (और इसलिए संस्करण नियंत्रण में होना चाहिए), लेकिन एक अनुभाग है जिसे सभी को स्वयं के लिए संपादित करने की आवश्यकता है। शायद एक डेटाबेस कॉन्फ़िगरेशन, या उपयोगकर्ता नाम और पासवर्ड, या किसी तीसरे पक्ष के सॉफ्टवेयर के लिए स्थानीय पथ। इस स्थिति में आपके विकल्प

1. संस्करण नियंत्रण में युद्ध संपादित करें। बस फ़ाइल को बदलते रहें और आशा करें कि आपके द्वारा किए जाने से पहले हर कोई फ़ाइल को संपादित कर देगा।

2. इसे संपादित करें, लेकिन उन परिवर्तनों को कभी भी प्रतिबद्ध न करें। वे बस "नया क्या है/बदले" कमांड को गंदा लगते हुए वहां बैठते हैं, और आपको इसे प्रतिबद्ध नहीं करना याद रखना होगा।

3. इसे टेम्पलेट करें। संस्करण नियंत्रण से फ़ाइल को हटाएं और अंत में। टेम्पलेट के साथ इसकी एक प्रतिलिपि में जांचें। स्थानीय रूप से फ़ाइल की प्रतिलिपि बनाएँ और इसे वापस बदलें,

4. नई (काल्पनिक?) लगातार स्थानीय परिवर्तन सुविधा का उपयोग करें। अपना परिवर्तन करें, फिर रिकॉर्ड-परिवर्तन-जैसे-स्थानीय-लगातार कमांड जारी करें, जो एक पैच का आंकड़ा बताता है, और प्रत्येक अपडेट के बाद आपके पैच का पुन: उपयोग होता है।

क्या यह सुविधा कहीं भी मौजूद है (यह गिट स्टैश की तरह लगता है, लेकिन उद्देश्य थोड़ा अलग है)? यदि यह अस्तित्व में नहीं है, तो क्या कोई अच्छा कारण नहीं है? (कोई है इसके बारे में सोचा और फैसला किया कि यह एक बुरा विचार था?)

Answer 1

आप इसे मास्टर (या "विक्रेता") शाखा और स्थानीय शाखा के साथ गिट में कर सकते हैं। आपकी स्थानीय गतिविधियां स्थानीय शाखा में जाती हैं, और जब आप बदलते हैं तो मास्टर के शीर्ष पर आप इसे फिर से दबाते हैं। यदि आप स्थानीय शाखा के लिए रिमोट निर्दिष्ट नहीं करते हैं तो आप इसे गलती से धक्का नहीं दे पाएंगे; यदि आप गलती से कुछ ऐसा करते हैं जो आप स्थानीय शाखा में बने रहना चाहते हैं, तो बस चेरी-मास्टर से आगे बढ़ें और वहां से धक्का दें।

Answer 2

यदि आप एक काम कर पेड़ में कई खजाने को जोड़ सकते हैं यह संभव है। सबसे सरल समाधान symlinks होगा।

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

कई खजाने के साथ, आप निश्चित रूप से करता है कि एक भंडार या अन्य में जाना हो सकता है। यह आवश्यक स्थानीय सेटअप वीसीएस सिस्टम पर निर्भर करता है। उदाहरण के लिए, के लिए SVN: बाहरी, आप प्रत्येक मशीन पर एक ही file: भंडार का उपयोग करने की आवश्यकता होगी, लेकिन वे फ़ाइलों के विभिन्न सेट को इंगित कर सकते हैं। सिम्लिंक के साथ, आप इसे किसी भी रूप में व्यवस्थित कर सकते हैं (मान लें कि सिम्लिंक स्वयं संस्करण नहीं है)।

Answer 3

मैं हमेशा स्थिति को पूरी तरह से बचने के लिए काम करके इस को सुलझा लिया है।

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

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

पासवर्ड और सीआई और परीक्षण वातावरण के लिए विन्यास में जाँच की है, तो निर्माण और तैनाती सर्वर स्वचालित रूप से परीक्षण के वातावरण में सिस्टम को लाने के कर सकते हैं कर रहे हैं। उत्पादन के लिए

पासवर्डों में जाँच की कभी नहीं किया है (कि अक्सर एक कानूनी आवश्यकता जहाँ मैं काम है) और प्रशासकों उत्पादन वातावरण में पासवर्ड फ़ाइल बनाए रखें।

Answer 4

मैं monotone पर एक समान काम करते हैं, propagate आदेश का उपयोग।

संक्षेप में

, मैं एक 'विकास' शाखा और एक 'तैनात' शाखा है। तैनात शाखा में, कॉन्फ़िगरेशन में कुछ सेटिंग्स अलग होती हैं (कुछ निर्देशिकाएं और DEBUG = गलत)। जब मैं तैनाती करना चाहता हूं, तो मैं विकास से तैनात शाखा में mtn propagate करता हूं। फिर सर्वर पर मैं एक पुल और अपडेट करता हूं, इसलिए वर्कस्पेस को अपनी शाखा से नवीनतम परिवर्तन मिलते हैं, जिसमें सभी नए विकास शामिल होते हैं, लेकिन सेटिंग अंतरों का सम्मान करते हैं।

Answer 5

आप संस्करण नियंत्रण से किसी भी कॉन्फ़िगरेशन फ़ाइल को अनदेखा कर सकते हैं। यह .gitignore फ़ाइल है।

उदाहरण के लिए यदि आप अपने सभी लॉग निर्देशिका अनदेखा करना चाहते, तो आप एक लाइन है कि फाइल करने के लिए के साथ जोड़ें:

.DS_Store 

:

log/* 

.DS_Store फ़ाइल को अनदेखा करने के लिए, आप के साथ एक पंक्ति जोड़ें

फिर आप स्थानीय रूप से फ़ाइल को अपडेट कर सकते हैं, आप इसे संशोधित लेकिन असामान्य फ़ाइलों में कभी नहीं देख पाएंगे। और यदि आप git add . करते हैं, तो इसे प्रतिबद्ध में जोड़ा नहीं जाएगा।

उस Git करने के लिए अपने विन्यास फाइल डाल करने के लिए, लेकिन केवल इसे से बाहर कहीं एक पासवर्ड या वर रखने के लिए, मैं क्या है कि विन्यास फाइल के अंदर एक दूर फ़ाइल बुला रहा है की जरूरत है। और इस फ़ाइल में मेरा पासवर्ड है।

उदाहरण के लिए एक रेल परियोजना पर, मेरे डेटाबेस विन्यास कि तरह लग रहा है:

production: 
database: project_database 
username: database_user 
password: <%= File.read('path/to/my/password/file').chomp if File.readable? 'path/to/my/password/file' %> 

फ़ाइल "पथ// मेरी/पासवर्ड/फाइल करने के लिए" संस्करण नियंत्रण में नहीं है।
तो मेरी कॉन्फ़िगरेशन फ़ाइल संस्करणित है। लेकिन पासवर्ड उस मशीन पर निर्भर करता है जिस पर हम हैं।

यह भी अपने संस्करण नियंत्रण में पासवर्ड नहीं होने का लाभ दिया है संभवतः किसी के द्वारा पढ़ने के लिए।

Answer 6

यह विजुअल स्टूडियो के लिए थोड़ा और विशिष्ट हो सकता है लेकिन मुझे लगता है कि अधिकांश आईडीई में कुछ समान सुविधा होगी।

मेरे एप्लिकेशन/वेब कॉन्फ़िगरेशन सेटिंग्स है कि विभिन्न वातावरण मैं उन्हें अपने फ़ाइलों में विभाजित के लिए बदल दिया है की सभी में इतना है कि मेरी मुख्य config प्रत्येक फ़ाइल के लिए यह

के समान है इस

<dataConfiguration configSource="Config\Development\dataConfiguration.config" /> 
    <connectionStrings configSource="Config\Development\connectionStrings.config" /> 
    <appSettings configSource="Config\Development\appSettings.config"/> 

तब की तरह दिखता है

<?xml version="1.0" encoding="utf-8" ?> 
<dataConfiguration defaultDatabase="defaultDatabase"/> 

इसके बाद मैं प्रत्येक पर्यावरण देव/स्टेजिंग/प्रोड आदि के लिए फ़ोल्डर्स बनाता हूं और प्रत्येक फ़ोल्डर में एक अलग उप कॉन्फ़िगरेशन फ़ाइल का उपयोग करता हूं ताकि सभी सेटिंग्स को टीएफएस में चेक किया जा सके। मेरे पास प्रति रिलीज कॉन्फ़िगरेशन उचित फ़ाइलों में खींचने के लिए मेरा वेब परिनियोजन प्रोजेक्ट सेटअप है।बाद में जब मैं अपनी रिलीज को प्रबंधित करने के लिए टीएफएस को कॉन्फ़िगर करता हूं तो इसे सही कॉन्फ़िगरेशन की प्रतिलिपि बनाकर आसानी से हासिल किया जा सकता है।

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

Answer 7

Darcs यह प्रदान करता है। आप अपने स्थानीय भंडार में सेटिंग्स में बदलावों का एक पैच रिकॉर्ड कर सकते हैं और इसे किसी अन्य भंडार में कभी भी धक्का नहीं दे सकते। अफसोस की बात है, FAQ states पैच को केवल स्थानीय के रूप में चिह्नित करना संभव नहीं है।

एक बार इस सीमा के आसपास काम कर सकता है हालांकि एक दूसरा भंडार है जिसमें केवल आपके भंडार के लिए अद्वितीय पैच शामिल हैं।

Answer 8

आप एसवीएन के साथ ऐसा कर सकते हैं।

आप बाद में पुस्तकालय के बाहर एक फ़ाइल को चेक करते हैं और उसमें परिवर्तन कर, और फिर एक "अद्यतन" करते हैं, आप अपने परिवर्तनों को लागू किया गया पुस्तकालय से फ़ाइल के नए प्रतिलिपि प्राप्त। मैं इसे विन्यास फाइलों के लिए नियमित रूप से उपयोग करता हूं।

यह आपके जैसा वर्णन नहीं कर रहा है, क्योंकि यह हर बार जब आप प्रतिबद्ध करते हैं, तो आपको कॉन्फ़िगरेशन फ़ाइल को बाहर करना होगा। मुझे लगता है कि अगर आप किसी बिंदु पर ऐसा करना भूल जाते हैं, तो आप अपने स्थानीय परिवर्तनों के साथ भंडार को अपडेट करेंगे और हर किसी को कुछ दुःख का कारण बनेंगे।

और जब आप कॉन्फ़िग फ़ाइल की "सार्वजनिक" भाग को बदलने की जरूरत है, तो आपको एक अलग जांच करने के लिए तो आप को अलग कर सकता "स्थानीय" परिवर्तन से "सार्वजनिक" बदलाव हैं।

मैं क्रिस मैरिसिक जैसे योजनाओं का भी समर्थन करता हूं। मेरे पास कुछ वेब ऐप्स हैं जहां मैंने एकाधिक कॉन्फ़िगरेशन फाइलें बनाई हैं, और प्रोग्राम गतिशील रूप से निर्णय लेता है कि पर्यावरण के आधार पर कौन सा उपयोग करना है।

एक मामले में, विन्यास फाइल बाहरी फ़ाइलों के लिए पथ शामिल है, और मैं दोनों एक Windows सर्वर और एक लिनक्स सर्वर के साथ काम कर रहा था तो पथ नाम अलग हैं। तो मैंने एक "लिनक्स कॉन्फ़िगरेशन" और "विंडोज कॉन्फ़िगरेशन" बनाने और फिर किस ओएस के तहत चल रहा था, इस पर आधारित है।

दूसरे मामले में, स्टार्टअप पर प्रोग्राम सर्वलेट संदर्भ (यह एक जेएसपी/सर्वलेट ऐप है) का नाम जांचता है, फिर "वेब-आईएनएफ/.properties" नाम की एक फ़ाइल की तलाश करता है। अगर ऐसा नहीं मिलता है, तो यह एक डिफ़ॉल्ट नाम लोड करता है। फिर मैं एक अलग संदर्भ नाम के तहत विकास संस्करण चलाता हूं, फिर उत्पादन संस्करण, और प्रत्येक स्वचालित रूप से सही कॉन्फ़िगरेशन फ़ाइल को उठाता है।

Answer 9

Mercurial एक स्थानीय फ़ाइल को .hgignore में जोड़ सकता है और इसलिए अनदेखा किया जा सकता है - तो यह आपकी बदली हुई फ़ाइलों या जो कुछ भी गड़बड़ नहीं करता है।