स्रोत नियंत्रण का आविष्कार कब किया गया था?

Question

मैं कई संस्करण नियंत्रण प्रणालियों से अवगत हूँ: CVS, SVN, TFS आदि ...

मैंने पहले "रिविजन कंट्रोल / वर्जन कंट्रोल सिस्टम" के लिए गुगुल लिया है और विभिन्न परस्पर विरोधी उत्तर देखे हैं।

स्रोत नियंत्रण का आविष्कार कब किया गया था? इसका अविष्कार किसने किया? इसको क्या कहा जाता था?

Comments

10 के लिए स्टार्टर: SCCS "मूल रूप से विकसित किया गया था ... 1972 में"

— आकाशवाणी

यह वास्तव में कई बार आविष्कार किया गया था, लेकिन वे स्रोत कोड खो देते रहे।

— रिएक्टगुलर

यह इस बात पर निर्भर करता है कि आप "स्रोत नियंत्रण" को कैसे परिभाषित करते हैं, लेकिन IBM का IEBUPDTE 1962 का है, और यह यकीनन सबसे शुरुआती VCS था।

— रोस पैटरसन

यदि संस्करण फ़ाइल सिस्टम को पुनरीक्षण नियंत्रण के लिए आत्मसात किया जा सकता है, तो यह 1960 के दशक की है।

— मौवीसील

@RossPatterson, उस टिप्पणी का वास्तव में उत्तर होना चाहिए।

— जॉन आर। स्ट्रोह्म

Answer 1

यहां वीडियो फॉर्म (कोई आवाज नहीं) में प्रमुख खिलाड़ियों की एक बहुत ही सभ्य समयरेखा है।

यह बताता है कि SCCS पहले, लगभग 9 वर्षों के अंतर से था।

इस ब्लॉग और इसके परिणामस्वरूप टिप्पणियों के सबूत के रूप में वहाँ बहुत कुछ गायब है ।

Comments

SCCS पर मूल कागज कोई अन्य प्रणालियों का उल्लेख है, और संकेत मिलता है कि यह शब्दावली ही साथ आने के लिए किया था लगता है। अकेले उस स्रोत से ऐसा लगता है जैसे 1972/73 से पहले कोई संस्करण नियंत्रण प्रणाली नहीं थी।

— Martijn Pieters

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

— इंगो

@MartijnPieters Rochkind पेपर के अंत में ब्राउन के CLEAR को स्वीकार करता है, और सीधे शब्दों में, OS / MVT पर SCCS का निर्माण करता है, वह IEBUPDTE से अनभिज्ञ नहीं हो सकता था।

— रॉस पैटरसन

@RossPatterson: न तो CLEAR और न ही IEBUPDTE स्रोत नियंत्रण प्रणाली हैं। CLEAR को डेल्टास के विचार का श्रेय दिया जाता है, यह स्पष्ट रूप से कागज में बताता है कि कोई अन्य समानताएं नहीं हैं।

— मार्टिज़न पीटरर्स

Answer 2

1981 में, मैंने ऑस्टिन TX में चार्टर इंफॉर्मेशन में एक ग्रीष्मकालीन नौकरी की। वे पहले वॉबर्न एमए के वाणिज्यिक सूचना निगम थे। उन्होंने एक ज़ेरॉक्स सिग्मा 6 चलाया जो कि सिग्मा 7. के लिए फील्ड-अपग्रेड किया गया था। उन्होंने सोर्स कोड कंट्रोल के लिए SPUD (सोर्स प्रोग्राम अपडेट) नामक चीज़ का इस्तेमाल किया। यह टेप आधारित था।

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

जबकि यूटी ऑस्टिन (1973-1981) में एक छात्र, मैं सीडीसी 6600 और बाद में मेनफ्रेम के लिए कंट्रोल डेटा कॉरपोरेशन से दो स्रोत कोड नियंत्रण कार्यक्रम MODIFY और UPDATE के खिलाफ भाग गया। मुझे नहीं पता कि वे पहली बार कब बाहर आए थे, लेकिन मुझे संदेह है कि वे 6600 के बाद लंबे समय तक बाहर नहीं आए, जो (यदि स्मृति मुझे सेवा देती है) 1960 के दशक के उत्तरार्ध में सामने आई थी।

मुझे संदेह है कि आईबीएम के पास किसी और के होने से पहले कुछ अच्छा था, लेकिन मुझे आईबीएम मेनफ्रेम इतिहास के बारे में कोई जानकारी नहीं है, और मुझे यह पसंद है।

Comments

CDC MODIFY और UPDATE कमांड सॉफ़्टवेयर अपडेट को लागू करने के लिए उपयोगिताओं थे, न कि आपके स्वयं के सॉफ़्टवेयर में परिवर्तनों को प्रबंधित करने के लिए, जहाँ तक मैं कर सकता हूँ। Apps.dtic.mil/dtic/tr/fulltext/u2/a208003.pdf देखें , जिसमें पृष्ठ पर 52 (पीडीएफ में 61) पृष्ठ की उपयोगिताओं का वर्णन किया गया है, और कंप्यूटिंगहिस्ट्री डॉट ओआरयूके / 29256 , जो वर्णन करता है # 4 प्रारूप में सॉफ्टवेयर रिलीज सामग्री (पीडीएफ # 16) अद्यतन प्रारूप में आने के रूप में।

— मार्टीजन पीटरर्स

मेरा मानना ​​है कि ज़ेरॉक्स SPUDS (सोर्स प्रोग्राम अपडेट डिस्क सिस्टम) एक समान पैकेज था।

— मार्टिज़न पीटरर्स

Answer 3

IEBUPDTE कार्यक्रम, मूल रूप से आईबीएम के OS / 360 प्रणाली के लिए बनाया, दिनांक 1962 तक वापस, से अधिक 10 साल पुराने SCCS । इसका उद्देश्य संशोधित स्रोत कार्यक्रमों का एक सेट बनाते हुए, इनपुट स्रोत कार्यक्रमों के एक सेट में परिवर्तन का एक सेट लागू करना है। सभी स्रोत कोड या तो 80-कॉलम वाले कार्ड के "डेक" के रूप में प्रबंधित किए गए थे , या उन फ़ाइलों के रूप में, जो उनके समान थीं । इन स्रोत प्रोग्राम डेक में प्रत्येक पंक्ति या कार्ड ( COBOL) पर कॉलम के एक निश्चित सेट में "अनुक्रम संख्या" थीउन्हें बायीं ओर होने के लिए निर्दिष्ट किया, स्तंभ 1-6 में, लगभग सब कुछ उन्हें कॉलम 73-80 में दाईं ओर माना जाता है)। अनुक्रम संख्याओं को लाइन से बढ़ाना था, लेकिन बाद के सम्मिलन के लिए दो लाइनों के बीच अभिन्न संख्या स्थान में कमरे की अनुमति देने के लिए अधिकांश स्रोत कोड में 10s, 100s या अधिक की वृद्धि हुई।

एक विशिष्ट IEBUPDTE नियंत्रण डेक की तरह लग सकता है:

./ CHANGE NAME=PROG001
         PROGRAM XYZZY                                                  00005000
./ DELETE SEQ1=9000,SEQ2=15000
         DO I=1,10                                                      00026000
./ CHANGE NAME=PROG002
         J=256                                                          00092000
./ ENDUP

जो दो स्रोत फ़ाइलों को संशोधित करेगा, "PROG001" और "PROG002", लाइन नंबर "5000" (अक्सर 5 वीं पंक्ति की जगह, "हजारों की संख्या में" अभ्यास के बाद) और PROG001 में 15000 के माध्यम से लाइनों को हटाने और PROG002 में लाइन 92000 की जगह। ।

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

Comments

IEBUDTE एक सॉफ्टवेयर अपडेट सिस्टम नहीं है? यह पैच के समान है, इसलिए संस्करण नियंत्रण प्रणाली का सबसे अच्छा घटक है। समय के माध्यम से परिवर्तनों का कोई ग्राफ नहीं है, जहां तक ​​मैं बाहर कर सकता हूं।

— मार्टिज़न पीटरर्स

हाँ, IEBUPDTEके समान है patch।

— रॉस पैटरसन