फ़ाइल इतिहास: स्रोत में या एससीएम इसे संभालने दें?

Question

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

मुझे फ़ाइल इतिहास को स्रोत फ़ाइल के शीर्षलेख में क्यों रखना चाहिए? क्या मुझे अपनी परिवर्तन टिप्पणियों के साथ इतिहास का प्रबंधन करने देना चाहिए?

Answer 1

स्रोत नियंत्रण प्रणाली इसे संभालने दें।

यदि आप हेडर में परिवर्तन विवरण डालते हैं तो यह जल्द ही अनावश्यक हो जाएगा और वास्तविक कोड को जबरदस्त कर देगा।

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

मुझे इसका अनुभव है। मेरे पास टिप्पणियों में फ़ाइल इतिहास है, यह भयानक था। कचरे के अलावा कुछ भी नहीं, कभी-कभी आपको अंत में प्राप्त होने से पहले कोड परिवर्तनों की लगभग 1k लाइनों को स्क्रॉल करना होगा। उल्लेख नहीं है, आप अपने स्रोत कोड पेड़ में अधिक केबी जोड़ कर अपनी बिल्ड प्रक्रिया के अन्य पहलुओं को धीमा कर रहे हैं।

Answer 6

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

Answer 7

एससीएम सिस्टम को चेकइन टिप्पणियों को संभालने के लिए एक और वोट, लेकिन मेरे पास जोड़ने के लिए एक चीज है।

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

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

लेकिन यह सिर्फ एक टिप्पणी है जो आप कहते हैं! सच है, लेकिन मेरे पास एक ऐसा मामला था जहां मेरी स्रोत फ़ाइल में कोड था, जो कि को आरसीएस हेडर टैग की तरह अजीब रूप से पर्याप्त कारण था और कोड का वह अनुभाग चेकइन पर बदल दिया गया था, जिससे मेरा कोड मंग कर रहा था। ठीक करने के लिए काफी आसान है, लेकिन खराब है कि 20+ उपयोगकर्ताओं के लिए एक बिल्ड टूटा गया

Answer 8

अंतर यह नहीं है कि यह एक केंद्रीकृत या वितरित वीसीएस है, यह क्या बदला जा रहा है इसके बारे में अधिक है।

जब मैं .NET में स्थानांतरित हुआ, तो किसी भी व्यक्तिगत परिवर्तन के लिए अपडेट की गई फ़ाइलों की संख्या आसमान लगती थी। अगर मुझे प्रत्येक फाइल में बदलाव लॉग करना पड़ा, तो मुझे कभी भी कोई वास्तविक काम नहीं मिलेगा। परिवर्तनों के सेट पर टिप्पणी करके, इससे कोई फ़र्क नहीं पड़ता कि मुझे कितनी फ़ाइलों को अपडेट करना था।

यदि मुझे किसी विशेष परिवर्तन के लिए सभी परिवर्तनों की पहचान करने की आवश्यकता है, तो मैं परियोजना के दो संस्करणों के बीच अंतर कर सकता हूं।

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

(एक साइड इफेक्ट के रूप में, मैंने पाया है कि मेरी प्रक्रिया विवरण टिप्पणियां बेहतर हो गई हैं)