जब आप संस्करण नियंत्रण का उपयोग कर रहे हैं तो क्या हर कोड फ़ाइल में "परिवर्तन लॉग" शामिल करने का कोई बिंदु है?

Question

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

// 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999

तथा:

// 2009-95-12 (Bob Jones) Extracted this code to Class Foo 
// <commented-out code here>

इसका कारण, जैसा कि मुझे समझाया गया था, यह है कि हमारे वीसीएस लॉग के माध्यम से झारना करने में बहुत लंबा समय लगता है, यह जानने की कोशिश करता है कि किसने और क्यों बदला, जबकि कोड फ़ाइल में ही, शीर्ष पर या संबंधित के पास है। परिवर्तन, यह देखना आसान बनाता है कि किसने और कब बदला। जब मैं उस बिंदु को देखता हूं, तो यह बेमानी लगता है और "ईह हम वास्तव में समझ नहीं पा रहे हैं कि हमारे वीसीएस का सही उपयोग कैसे किया जाए।"

तुम क्या सोचते हो? क्या आप टिप्पणियों और लॉग दोनों का उपयोग करते हैं? बस लॉग? क्या आपको लगता है कि जब आप कोड के एक ब्लॉक के ऊपर देख सकते हैं तो कोड को ब्लॉक करना आसान है कि जॉन स्मिथ ने लॉग के माध्यम से खोज करने और एक डिफ टूल में कोड फ़ाइलों की तुलना करने के बजाय एक सप्ताह पहले XYZ के लिए जाँच करने का तरीका बदल दिया?

संपादित करें: SVN का उपयोग करना, लेकिन मूल रूप से केवल एक भंडार के रूप में। कोई शाखा नहीं, कोई मर्ज नहीं, लॉग + स्टोरेज के अलावा कुछ भी नहीं।

Comments

आप किस संस्करण नियंत्रण प्रणाली का उपयोग कर रहे हैं?

— ChrisF

स्रोत नियंत्रण प्रणाली से पहले कुछ दुकानें परिवर्तन लॉग का उपयोग करती थीं। जड़ता और परिचितता परिवर्तन लॉग को चारों ओर रखती है।

— गिल्बर्ट ले ब्लैंक

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

— Slaphappy

+1 - मैं इस बारे में लगभग दो वर्षों से अपने वरिष्ठ देव से लड़ रहा हूँ। इन बेकार टिप्पणियों को जोड़ने के लिए उनका एकमात्र तर्क यह है कि यह 3000-लाइनों के तरीकों में विलय को थोड़ा आसान बनाता है। यह विचार कि 3000-लाइन विधि अश्लील है, स्कॉर से मिला है।

— जोशुआ स्मिथ

यदि "[अपने] वीसीएस लॉग" के माध्यम से झारना करने में बहुत लंबा समय लगता है, तो आप कुछ गलत कर रहे हैं।

— कीथ थॉम्पसन

Answer 1

मैं कोड में टिप्पणियों को हटाना चाहता हूं। और हटाने से मेरा मतलब है कि पूर्वाग्रह के साथ । जब तक कोई टिप्पणी नहीं बताती है कि कोई विशेष कार्य कुछ क्यों करता है, तो वह चला जाता है। अलविदा। पास मत जाना।

तो यह आपको आश्चर्यचकित नहीं करना चाहिए कि मैं उन चेंजलॉग्स को भी उसी कारण से हटा दूंगा।

कोड और टिप्पणियों के साथ समस्या जो पुस्तकों की तरह पढ़ी जाती है, वह यह है कि आप वास्तव में नहीं जानते कि यह कितना प्रासंगिक है और यह आपको यह समझने का झूठा एहसास देता है कि कोड वास्तव में क्या करता है।

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

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

लेकिन ऐसा न हो कि आपको लगता है कि मैं कहता हूं कि टिप्पणियों को जेस्ट में हटा दिया जाना चाहिए, यह डेली डब्ल्यूटीएफ सबमिशन (मेरे द्वारा काम किए गए कोडबेस से) मेरी बात को पूरी तरह दिखाता है:

/// The GaidenCommand is a specialized Command for use by the
/// CommandManager.
///
/// Note, the word "gaiden" is Japanese and means "side story",
/// see "http://en.wikipedia.org/wiki/Gaiden".
/// Why did I call this "GaidenCommand"? Because it's very similar to
/// a regular Command, but it serves the CommandManager in a different
/// way, and it is not the same as a regular "Command". Also
/// "CommandManagerCommand" is far too long to write. I also toyed with
/// calling this the "AlephCommand", Aleph being a silent Hebrew
/// letter, but Gaiden sounded better.

ओह ... कहानियाँ मैं आपको उस कोडबेस के बारे में बता सकता था, और मैं इसके अलावा, यह अभी भी सबसे बड़े सरकारी संगठनों में से एक के उपयोग में है।

Comments

जब भी मैं किसी विशेष तर्क-वितर्क के साथ संघर्ष करता हूं, तो टिप्पणी कभी-कभी मुझे कुछ संदर्भ देने में मदद करती है कि तर्क उतना ही जटिल क्यों है जितना कि है। लेकिन पूरे पर मैं आपसे सहमत हूं।

— maple_shaft

हर डेवलपर में कम से कम कुछ बुरे गुण होते हैं, मुझे पता है कि मुझे नहीं करना चाहिए, लेकिन मैं बस रोक नहीं सकता :) हर बार जब मैं एक TODOटिप्पणी करता हूं तो एक पिल्ला मर जाता है।

— maple_shaft

पूर्वाग्रह के साथ अन्य लोगों की टिप्पणियों को हटाना एक तरह से आपकी स्वयं की प्रोग्रामिंग शैली और दूसरों पर विश्वास करने के लिए मजबूर करना है। जूनियर और पैसिफिस्टिक प्रोग्रामर पीछे नहीं हटेंगे, लेकिन एक बार जब आप एक अल्फा पुरुष में दौड़ते हैं, और फिर एक लड़ाई जो शुरू नहीं होनी चाहिए थी। तो, आपने एक स्मार्ट व्यक्ति के स्मार्ट ब्लॉग पर पढ़ा है कि जब टिप्पणियों की बात आती है, तो कम होता है। अन्य लोगों ने शायद एक ही पुस्तक नहीं पढ़ी होगी। यहां तक ​​कि अगर आपको लगता है कि आप सही हैं, क्योंकि एसओ पर कुछ लोग 5k + प्रतिनिधि के साथ काम करते हैं, तानाशाही सहयोगी काम के बारे में जाने का तरीका नहीं है। मैंने पहले एक अल्फा पुरुष के तहत काम किया और छोड़ दिया।

— जॉब

@ नील बटरवर्थ: पुनः: नीलामी: कोड का मतलब निंदनीय है। इसे रिफलेक्टर करें, इसे बदलें, इसमें सुधार करें। यह उसके लिए है। यह सिर्फ एक बार लिखे जाने के लिए नहीं है। व्यवसाय की हमारी समझ बदल जाती है और जब ऐसा होता है तो हमें कोड बदलने की आवश्यकता होती है। मुझे टिप्पणियों के साथ बहुत सारी समस्याएं हैं, लेकिन हमारी चर्चा के लिए सबसे अधिक प्रासंगिक यह है कि टिप्पणियाँ कोड के साथ शायद ही कभी रहती हैं, और आम तौर पर वे यह नहीं समझाते हैं कि कुछ क्यों हो रहा है। जब ऐसा होता है, तो इसे हटाना आसान होता है। अगर कोई मेरे पास आता है और पूछता है कि मैंने निम्नलिखित टिप्पणी क्यों हटाई है file.Open() // Open the file। मैं हंस पड़ा।

— जॉर्ज स्टॉकर

कुछ दिन पहले, मैंने कोड का एक टुकड़ा लिखा था, त्रिकोणमिति, परिवर्तनों से भरा बहुत ही जटिल गणितीय गणना, जो भी ... मुझे कोड की कम और फिर 10 पंक्तियों को लिखने में लगभग आधे घंटे का समय लगा। मेरे आस-पास बहुत सुंदर कोई नहीं समझता कि यह कैसे काम करता है। मैं इसे कुछ हफ्तों में भी समझ नहीं पाऊंगा। दूसरी ओर, इसका तुच्छ क्यों है। तो, उन कुछ पंक्तियों के ऊपर, पाठ का एक पूरा अध्याय है, जो समझाता है कि क्यों नहीं। यदि आप आते हैं और उस टिप्पणी को हटा देते हैं, तो मैं आपके चेहरे पर मुक्का मारता, पेंच फँस जाता।

— odralo

Answer 2

कोड में एम्बेड किए गए "परिवर्तन-लॉग" विशेष रूप से naff हैं। जब आप संशोधन करते हैं, तो वे बस एक और अंतर दिखाते हैं, और एक ऐसा जिसे आप वास्तव में परवाह नहीं करते हैं। अपने VCS पर भरोसा करें - अधिकांश में एक "दोष" सुविधा है जो आपको बहुत तेज़ी से दिखाएगी कि किसने क्या बदला।

निश्चित रूप से वास्तव में भयानक बात यह थी कि "पुराने समय" वीसीएस की सुविधा जहां आप वास्तविक वीसीएस लॉग को स्रोत फ़ाइलों में एम्बेड कर सकते थे। विलय लगभग असंभव हो गया।

Comments

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

— बेन हॉकिंग

Answer 3

मेरे पास प्रत्येक प्रोजेक्ट के लिए एक एकल चेंजलॉग फ़ाइल है जो कुछ प्रतिबद्ध संदेशों द्वारा स्वचालित रूप से पॉपुलेटेड है।

हमारे पास ChangeLog टिप्पणियाँ नहीं हैं। अगर हम करते तो मैं उन्हें हटा देता और उन्हें जोड़ने वाले व्यक्ति के साथ एक "बात" करता। मुझे लगता है कि वे आपके द्वारा उपयोग किए जाने वाले उपकरणों, विशेष रूप से vcs को नहीं समझने के संकेत हैं।

हमारे पास प्रतिबद्ध संदेशों के लिए एक प्रारूप है जो लॉग्स को संक्षिप्त करना आसान बनाता है। हम बेकार या अस्पष्ट प्रतिबद्ध संदेशों को भी अस्वीकार करते हैं।

Answer 4

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

लेकिन मैं क्या जानता हूं...

मुझे लगता है कि अगर स्रोत कोड के भीतर परिवर्तन लॉग रखने की प्रथा को लागू करने पर जोर दिया गया है तो परिवर्तन लॉग को उन परिवर्तनों तक सीमित किया जाना चाहिए जो वर्ग के pulic API / इंटरफ़ेस को प्रभावित करते हैं। यदि आप उस वर्ग के भीतर परिवर्तन कर रहे हैं जो किसी भी कोड को तोड़ने वाला नहीं है जो इसका उपयोग करता है, तो इन परिवर्तनों को एक परिवर्तन लॉग में दर्ज करना मेरे विचार में सिर्फ अव्यवस्था है। हालाँकि, मैं देख सकता हूँ कि कैसे कभी-कभी किसी भी बदलाव पर प्रलेखन के लिए स्रोत कोड फ़ाइल के शीर्ष की जांच करने में सक्षम होना आसान हो सकता है जिसने किसी और के लिए कुछ भी तोड़ दिया हो। बस इस बात का सारांश है कि परिवर्तन API को कैसे प्रभावित कर सकता है और परिवर्तन क्यों किया गया।

दूसरी ओर, मेरी दुकान मुख्य रूप से सी # सामान करती है, और हम हमेशा अपने एपीआई का दस्तावेजीकरण करने के लिए इनलाइन एक्सएमएल टिप्पणियों का उपयोग करते हैं, इसलिए सार्वजनिक एपीआई परिवर्तनों पर दस्तावेज़ीकरण पढ़ना कमोबेश सरल है।

मुझे लगता है कि स्रोत फ़ाइल के भीतर एक परिवर्तन लॉग पर जोर देना मशीन में अनावश्यक घर्षण जोड़ रहा है और पहले स्थान पर एक संस्करण नियंत्रण प्रणाली को लागू करने के उद्देश्यों में से एक को हरा देता है।

Answer 5

मैंने जिस अंतिम कंपनी में काम किया, उसके पास 17 साल का सॉफ्टवेयर था, जिसके पीछे इतिहास, विकास और वार्षिक अपडेट थे। एक संस्करण नियंत्रण प्रणाली से अगले तक सभी माइग्रेशन टिप्पणी या चेक-इन नोटों को संरक्षित नहीं करेंगे। न ही उन वर्षों में सभी डेवलपर्स ने चेक-इन टिप्पणियों / नोटों के साथ कोई निरंतरता बनाए रखी।

स्रोत कोड में टिप्पणियों के साथ, परिवर्तनों के पुरातत्व इतिहास को नोट के रूप में रखा गया था, कोड से टिप्पणी नहीं की गई थी। और, हाँ, वे अभी भी VB6 कोड शिपिंग कर रहे हैं।

Answer 6

संस्करण नियंत्रण कोड में उन परिवर्तन लॉग टिप्पणियों को बदल सकता है यदि आपकी टीम के देवता इसे सही उपयोग कर रहे हैं।

यदि आपकी टीम चेक-इन पर टिप्पणियां नहीं जोड़ रही है, या बेकार की टिप्पणियां छोड़ रही हैं, तो भविष्य में आपके द्वारा खोजी जा रही जानकारी को ढूंढना बहुत कठिन होगा।

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

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

Answer 7

यह उन दिनों से बचा हुआ है जब वीसीएस लॉग भ्रमित कर रहे थे और वीसीएस सिस्टम को संभालना मुश्किल था (मुझे याद है वे दिन, कहीं न कहीं 80 के बैकेंड में हैं)।

आपका संदेह पूरी तरह से सही है, ये टिप्पणियां मदद की तुलना में अधिक बाधा हैं और कोई भी आधुनिक वीसीएस आपको वही ढूंढने देगा जो आप ढूंढ रहे हैं। बेशक, आपको (और आपके सहयोगियों को) लगभग खर्च करना होगा। 30-60 मिनट सीखना कि इन सभी सुविधाओं को कैसे चलाना है (जो, मुझे संदेह है, वास्तव में यही कारण है कि ये टिप्पणियां अभी भी हैं)।

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

Answer 8

हम अभी भी उन्हें संग्रहीत कार्यविधि स्रोत में शामिल करते हैं क्योंकि यह है कि हम वास्तव में यह बता सकते हैं कि क्लाइंट में कौन सा संस्करण है। शेष एप्लिकेशन को संकलित वितरित किया गया है, इसलिए हमारे पास मॉड्यूल संस्करण संख्याएं हैं जो स्रोत से वापस लिंक करती हैं, लेकिन एसपी को स्थानीय-इन-डेटाबेस संकलन के लिए ग्राहकों को स्रोत के रूप में वितरित किया जाता है।

हमारी विरासत PowerBuilder कोड अभी भी उनका उपयोग करता है, लेकिन मुझे लगता है कि यह कुछ झांकियों के लिए एक आराम कारक के रूप में है। वह भी वितरण के लिए संकलित हो जाता है, इसलिए (IMO वे oughtta) फ्रिगिन VCS इतिहास का उपयोग करते हैं।

Comments

+1 मैं यह उत्तर लिखने जा रहा था लेकिन आपने मुझे परेशानी से बचा लिया। न केवल संग्रहीत प्रक्रियाओं को स्रोत के रूप में वितरित किया जाता है, बल्कि कई स्क्रिप्टिंग भाषाएं भी। मैं OpenACS और TCL का बहुत उपयोग करता हूं - अक्सर अगर किसी ग्राहक के पास किसी विशेष फ़ाइल का एक संस्करण होता है, तो केवल यह अनुमान लगाने का एक तरीका है कि आप जानते हैं कि परिवर्तन लॉग को पढ़कर उनके पास कौन सा संस्करण है। विशेष रूप से आसान है अगर आप एक ग्राहक की साइट में लॉग इन हैं और आसानी से संस्करण नियंत्रण सॉफ्टवेयर के साथ अलग नहीं कर सकते।

— ट्रोजननाम

Answer 9

यदि आप एसवीएन का उपयोग कर रहे हैं, तो ऐसा करना समय की बर्बादी है और पूरी तरह से बेकार है।

SVN का दोष कार्य है। यह आपको बताएगा कि किसी फाइल में हर लाइन किसने और कब बनाई।

Answer 10

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

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

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

और यह विचार करने से पहले है कि संगठन अपने संस्करण नियंत्रण प्रणाली को कुछ आवृत्ति के साथ बदलने का निर्णय ले सकते हैं, खासकर जब वे छोटी कंपनियों से बड़े डेवलपर्स से बहुत बड़ी कंपनियों तक बढ़ते हैं। ये माइग्रेशन अक्सर परिवर्तन लॉग टिप्पणियों के नुकसान का कारण बनेंगे - कोड में केवल टिप्पणियों को संरक्षित किया जाएगा।

Comments

क्या कोई VCS रूपांतरण हैं जो संदेशों को संरक्षित नहीं करते हैं?

— डेविड थॉर्नले

@ डेविड - मैंने बहुत देखा है जो नहीं किया। मुझे नहीं पता कि ऐसा करने में तकनीकी बाधाएँ थीं या क्या किसी ने फैसला किया कि यह "नए सिरे से शुरू करना" आसान है और 1 तारीख को नए वीसीएस में सभी कोड की जांच करें।

— जस्टिन केव

एक टिप्पणी जोड़ना यह बताते हुए कि एक प्रक्रिया क्यों बदली गई है , उपयोगी हो सकती है, और कभी-कभी एक टिप्पणी जोड़कर यह बताते हुए कि यह कब बदल गई, लेकिन मुझे उस टिप्पणी को परिवर्तन लॉग के रूप में डालने में योग्यता नहीं दिखती है। एक के लिए, यह कुछ हद तक टिप्पणी की उपयोगिता को समाप्त कर देता है ("ओह, यह सिर्फ एक परिवर्तन लॉग टिप्पणी है"), और दो, यह आगे, अनावश्यक परिवर्तन लॉग टिप्पणियों (# 1 को मजबूत करने) को प्रोत्साहित करता है।

— बेन होकिंग

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

— ebyrob

जैसा कि "बदलते स्रोत नियंत्रण" - लगभग सभी आधुनिक प्रणालियां इतिहास को एक-दूसरे तक ले जा सकती हैं, आउटपुट व्यक्तिगत प्रोजेक्ट स्तर परिवर्तन फ़ाइलें, या एक छोटे से प्रयास के साथ वास्तव में अपने परिवर्तन-लॉग को स्रोत फ़ाइल में एम्बेड कर सकती हैं (जब यह एक चाल पर उचित हो जाता है पहले नहीं)। तो प्रौद्योगिकी है, स्रोत नियंत्रण का ठीक से उपयोग नहीं करने वाले लोगों की समस्या है।

— ebyrob

Answer 11

मुझे यह देखकर आश्चर्य हुआ कि किसी ने भी इसका उल्लेख नहीं किया है, लेकिन लाइसेंस आवश्यकताओं के अनुपालन के लिए इसका मूल कारण नहीं है? यही है, कुछ लाइसेंस कहते हैं कि फ़ाइल में आपके द्वारा किए गए किसी भी परिवर्तन को फ़ाइल में ही नोट किया जाना चाहिए?

Comments

कौन से लाइसेंस कहते हैं?

— त्रासपलाजियो गार्जुग्लियो

मैंने एक ऐसी जगह पर काम किया, जहां सर्बेंस ऑक्सले अनुपालन करते थे, जो स्रोत फ़ाइलों में मांग वाले परिवर्तन ब्लॉकों में विश्वास करते थे। उन्होंने वर्षों के दौरान PVCS (उर्फ "आयाम") का भी उपयोग किया, इसलिए उनका वास्तव में कोई भी संस्करण नियंत्रण में नहीं था, लेकिन मुझे क्या पता था?

— ब्रूस एडिगर

@ मार्को: मुझे याद नहीं है या मैं इससे जुड़ा होगा।

— सेवर्रे रबेलियर

GPLv2 की धारा 2 ए को इसकी आवश्यकता है। अधिकांश परियोजनाएं इसे अनदेखा करती हैं, कुछ के पास एक "चेंजलॉग" फ़ाइल होती है (अक्सर उनके वीसीएस से उत्पन्न होती है)।

— dsas

Answer 12

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

Comments

व्यक्तिगत रूप से, मुझे यह थोड़ा सा दर्द होता है जब एक 200 लाइन फ़ाइल हर स्रोत फ़ाइल में एक चैंज जोड़ने के कारण 1,000 लाइनें लंबी हो जाती है। यह अतिरिक्त शोर वास्तव में अस्पष्ट करता है कि लंबे समय से पहले क्या महत्वपूर्ण है।

— ebyrob