80 और 90 के दशक में दिन के माइक्रो कंप्यूटर पर संस्करण नियंत्रण कैसे काम करता था?


31

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

आजकल हर कोई सोर्स कंट्रोल पर निर्भर है .. यह एक नॉन-ब्रेनर है। लेकिन 80 के दशक में, कंप्यूटर नेटवर्क स्थापित करना इतना आसान नहीं था, और सर्वोत्तम प्रथाओं जैसी चीजें अभी भी समझी जा रही थीं ...

मुझे पता है कि 70 और 60 के दशक में प्रोग्रामिंग बहुत अलग थी इसलिए संशोधन नियंत्रण आवश्यक नहीं था। लेकिन यह 80 और 90 के दशक में है कि लोगों ने कोड लिखने के लिए कंप्यूटर का उपयोग करना शुरू कर दिया, और अनुप्रयोग आकार और दायरे में बढ़ने लगे, इसलिए मैं सोच रहा हूं कि लोगों ने उस सब को वापस कैसे प्रबंधित किया।

इसके अलावा, यह प्लेटफार्मों के बीच कैसे भिन्न होता है? कहो Apple बनाम कमोडोर 64 बनाम Amiga बनाम MS-DOS बनाम विंडोज बनाम अटारी

नोट: मैं ज्यादातर दिन के माइक्रो कंप्यूटर पर प्रोग्रामिंग की बात कर रहा हूं , बड़ी यूनिक्स मशीनों की नहीं।


3
आरसीएस शुरू में 1982 में जारी किया गया था।
5gon12eder

1
लेकिन कितने लोगों ने इसका इस्तेमाल किया? RCS AFAIK यूनिक्स और यूनिक्स जैसी मशीनों के लिए बनाया गया था जो माइक्रो कंप्यूटर पर नहीं चलते थे।
9a3eedi

2
हमारे पास सिस्टम था। बस tcp / ip पर बसा नहीं था, अन्य भी थे, जैसे कि डीनेट। फ़ाइल-साझाकरण कई प्रोटोकॉल में उपलब्ध था। और टीमों ने माइक्रो के लिए भी मिनिस पर विकास किया, हालांकि कुछ छोटे स्वतंत्र डेवलपर्स (टीमों पर नहीं), बस औपचारिक नियंत्रण के साथ संस्करण के बजाय बैकअप किया। कुछ कठोर मैनुअल बैकअप के साथ संस्करण नियंत्रण का अनुकरण कर सकते हैं।
एरिक इद्दत

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

2
मेरे मामले में, हमने 1980 के दशक की शुरुआत में मिनी-कंप्यूटर के लिए पंच कार्ड के डेक का उपयोग किया था। कभी-कभी, हम पंच कार्ड फ़ाइल अलमारियाँ में स्रोत कोड डेक को सहेजते हैं।
गिल्बर्ट ले ब्लैंक

जवाबों:


22

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

1980 के दशक के मध्य से माइक्रो कंप्यूटर पर नेटवर्किंग एक विकल्प था, जिसे अक्सर "फाइल सर्वर" के रूप में एक यूनिक्स प्रणाली से जोड़ा जाता था (शायद फाइल को स्थानांतरित करने के लिए RS232 और Kermit का उपयोग करके, यूनिक्स प्रणाली पर SCCS के साथ)

एरिक सिंक द्वारा संस्करण नियंत्रण का इतिहास देखें कि पिछले कुछ वर्षों में संस्करण नियंत्रण प्रणाली कैसे बदल गई है।

मुझे याद है कि 1980 के दशक के उत्तरार्ध में "BYTE" में स्रोत कोड नियंत्रण के बारे में पढ़ना, इसलिए यह तब तक "छोटे सिस्टम" पर उपयोग में रहा होगा।

SourceSafe को 90 के दशक के मध्य में डॉस, विंडोज आदि पर चलने के द्वारा अच्छी तरह से स्थापित किया गया था।

यह लिंक 1994 से पीसी पर चलने वाले पीवीसीएस के बारे में एक लेख दिखाता है , यह संस्करण 6.2 पर है इसलिए स्पष्ट रूप से कुछ समय के लिए था, विकिपीडिया का कहना है कि यह 1985 से है


हालाँकि 1990 के दशक के उत्तरार्ध तक छोटे पैमाने के सॉफ्टवेयर पर काम करने वाले अधिकांश प्रोग्रामर द्वारा गिने जाने वाले फ्लॉपी डिस्क का उपयोग उनकी हार्ड डिस्क पर फ़ोल्डरों के साथ करने के लिए किया जाता था, जो हर दिन सोर्स कोड की एक कॉपी बनाते थे।

मुझे याद है कि यूनिट से विंडोज एनटी 3.5 तक एक प्रोजेक्ट पोर्टिंग सॉफ्टवेयर पर काम करना। प्रोग्रामर जो जानते हैं कि विंडोज के लिए प्रोग्राम कैसे करना है, उस समय अक्सर सोर्स कोड कंट्रोल के बारे में भी नहीं सुना था।


इस टाइमलाइन को एक ब्लॉग पोस्ट से लिया गया है , जिसमें कोडसक्वेयर है , वे प्लास्टिक एससीएम बेचते हैं, हालांकि अन्य प्रणालियों के इतिहास का अवलोकन उचित लगता है, आरसीएस से पहले की कुछ पुरानी प्रणाली छवि के बचे हैं।

संस्करण नियंत्रण इतिहास की समयरेखा


1
जब मैंने काम करना शुरू किया तो मैं वीएसएस का उपयोग कर रहा था .. मुझे नरक टिप्पणी का स्वागत पसंद है । मुझे याद है कि मेरी टीम लीड से पूछ रही है कि क्या यह लागू करने के लिए बदलने के लायक होगा ... नरक हाँ!
प्रातः

@draeron, मैंने पाया कि VSS ठीक था यदि आप शाखाओं को विलय करने में सक्षम होने की उम्मीद नहीं करते थे और यह एक स्थिर सर्वर सर्वर पर था। मैंने जिस कंपनी के लिए काम किया था, उसमें खराब रैम चिप वाले सर्वर पर था, इसलिए डेटाबेस को भ्रष्ट करता रहा! हालाँकि सप्ताह के किसी भी दिन के बजाय मुझे लागू करें ....
इयान

"नरक में आपका स्वागत है" क्लीयरकेस पर भी लागू हो सकता है ... कंपकंपी
एंड्रयू केनन

13

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

80 के दशक के मध्य से लेकर 90 के दशक के मध्य तक मैंने अक्सर फ़ाइल नाम के अंत में एक वर्जन नंबर का इस्तेमाल किया, जैसे "game.003"। तब मैं कोडांतरक में 90% प्रोग्रामिंग कर रहा था और सभी कोड एक बड़ी फ़ाइल में थे, संभवतः एक या दो में शामिल हैं, जहां मैंने मैन्युअल रूप से संस्करण संख्या को अपडेट करना होगा क्योंकि चीजें बदल गई थीं। मेरे पास एक स्थिर संस्करण होने के बाद मैं केवल संख्या बढ़ाता हूँ जो मुझे यकीन है कि मैं रखना चाहता था।

यह अंततः लगभग 3 लोगों के लिए कुछ हद तक आराम से बढ़ गया। उसके बाद हमने टीम बढ़ाई और एक साल तक सभी जगहों पर फाइलों की गड़बड़ी खत्म की और जब तक मैं तंग नहीं आया, तब तक मैं अलग-अलग लोगों के बदलावों को ट्रैक करने की कोशिश कर रहा था और हमने 1997-98 के आसपास पेरफोर्स का इस्तेमाल करना शुरू कर दिया।


6

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

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

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

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


1
जब तक Active Directory win2k के साथ लॉन्च नहीं हुई, नेटवेयर अभी भी बहुत प्रभावी था। अभी भी बहुत सारी चीजें हैं नेटवेयर ने अच्छी तरह से किया है कि एडी गंभीर बोल्ट-ऑन के बिना नहीं कर सकता।
व्याट बार्नेट

तो आप क्या कह रहे हैं कि उस समय माइक्रो कंप्यूटर वाले लोग स्रोत नियंत्रण का उपयोग नहीं करते थे क्योंकि उन्हें इसकी आवश्यकता नहीं थी? यानी यह आम तौर पर अपने घर में केवल एक कार्यक्रम बना रहा था, इसलिए कोड साझा करने या मर्ज करने की कोई आवश्यकता नहीं थी?
9a3eedi

2
@ 9a3eedi: मैं एक विशिष्ट चित्र बना रहा हूं। लोगों को जरूरत महसूस हुई होगी, लेकिन यह सिर्फ इसलिए नहीं था कि आप अपने साधनों से जीवित थे। आप कहते हैं विलय? यह एक बड़ा जटिल कार्यक्रम लगता है। ऐसे जानवर को कितनी स्मृति की आवश्यकता है? मर्ज किए जाने वाले कोड के लिए क्या शेष रहेगा? मैं फ्लॉपीज़ को स्वैप कर सकता हूं लेकिन अगर मेरी मेमोरी भर गई है, तो मैं कहां जाऊंगा ?! यह तब तक नहीं था जब तक लोगों को "सभी मेमोरी की आवश्यकता होगी जो उन्हें पसंद है" (जैसे 640K) कि यह भी संभव था।
मार्टिन माट

5

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


SCCS ने माइक्रो कंप्यूटर पर काम नहीं किया। और काम नहीं कर सका, क्योंकि यह सोलारिस के लिए विशुद्ध रूप से विशिष्ट सुविधा पर निर्भर था (सामान्य यूनिक्स भी नहीं) फाइलसिस्टम
gnat

1
@gnat - आप एक ही बात कर रहे हैं SCCS ? मुझे पता है कि मैंने इसे 90 के दशक के मध्य में एक नेक्स्ट पर इस्तेमाल किया था, और मेरा मानना ​​है कि मैंने 80 के दशक के अंत में विभिन्न गैर-सोलारिस यूनियनों पर इसका इस्तेमाल किया। और इससे जुड़ा विकिपीडिया लेख इस बात से सहमत होगा कि यह सोलारिस-ही नहीं था।
15:15 बजे kdgregory

3
बहुत यकीन है कि मैंने 1986 के आसपास 3B2-400 रनिंग Sys V पर SCCS का उपयोग किया था। ISTR कि हमने इसका उपयोग RCS के बजाय किया क्योंकि हम सलाहकार के साथ काम कर रहे थे, जिनकी कंपनी ने अपने Z8000-आधारित Xenix सिस्टम पर इसका इस्तेमाल किया था और उनके पास कुछ फाइफ़ाइल्स थे, जिन्होंने इसे ग्रहण किया इस्तेमाल किया गया था।
TMN

1
मैंने मोटोरोला 68000 प्रोसेसर पर चलने वाले Microsoft Xenix पर 1984 में निश्चित रूप से SCCS का उपयोग किया था।
चार्ल्स ई। ग्रांट

2
यह सच है कि लिनक्स ने 1980 के दशक में SCCS का समर्थन नहीं किया था। 1880 के दशक में SCCS के लिए लिनक्स समर्थन की कमी थी। 1980 के दशक के तहत SCCS और अन्य कार्यक्रमों (जैसे rn newsreader) ने यूनिक्स सलाहकार फ़ाइलों को बनाने के लिए ओपन (2) का उपयोग किया, जो सभी उपयोगकर्ताओं ने एक ही प्रोटोकॉल का पालन किया तो काम किया। चूंकि SCCS सलाहकार ताले बनाने वाला था, इसलिए उनका सम्मान करना निश्चित हो सकता है।
msw

1

मेरी पहली गर्मियों की प्रोग्रामिंग नौकरी जबकि मैं अभी भी स्कूल में वापस आ गया था (यह मुझे लगता है कि 91 होगा) मुझे लगता था कि मैं जिस छोटी सी कंपनी में काम कर रहा था उसके लिए एक स्वचालित संस्करण प्रबंधन और बैकअप प्रणाली लागू करना था। हमारे पास 3 पीसी एक नेटवेयर सर्वर के लिए झुका हुआ था, और मालिक अंत में संस्करण संघर्षों से निपटने के लिए थक गए थे और फ्लॉपी तक बैकिंग की आवश्यकता थी, इसलिए हमने डेवलपर्स को सर्वर पर संग्रहीत फ़ाइलों के बजाय सीधे अपने पीसी पर काम किया। जैसा कि उनके पास अब तक था, और मैंने एक ऐसी प्रणाली लिखी जो उनकी सभी फाइलों को केवल पढ़ने के लिए सेट रखती थी जब तक कि वे एक प्रोग्राम नहीं चलाते थे जो किसी और की जाँच नहीं करता था उनका उपयोग कर रहा था, फिर एक केंद्रीय btrieve डेटाबेस (एक साधारण क्वेरी के साथ एक संबंधपरक डेटाबेस) पर उपयोग रिकॉर्ड किया गया एपीआई बजाय पूर्ण sql जो netware सर्वर पर चला गया)। एक अन्य कार्यक्रम ने अपने संशोधित परिवर्तनों की जाँच की और उन्हें सर्वर पर कॉपी किया,

जबकि इस प्रणाली का निर्माण उस छोटी फर्म के लिए किया गया था जिस पर मैंने काम किया था, मुझे लगता है कि कई समान दुकानों में समान प्रक्रियाएं थीं।


1

व्यक्तिगत अनुभव से: 1985 एमएस-डॉस नेटवर्क विकसित पीवीसीएस उपलब्ध था और बहुत महंगा था। Apple और सभी गैर-MSDOS PC के लिए: कुछ भी नहीं। मैंने 1987 से T-lib ($ 50) का उपयोग किया। यूनिक्स बंदरगाहों (SCCS) ने 1990 के आसपास, 1992 के आसपास SourceSafe को छानना शुरू किया।

1995 तक, यदि आप VCS का उपयोग नहीं कर रहे थे, तो आप गंभीर नहीं थे।


मैं आखिरी वाक्य को 1985 में
बदलूंगा

@ चिह्न: मुझे बहुत संदेह है कि यह पीसी पर विकास के लिए सही था। कॉरपोरेट्स ने ज्यादातर विंडोज 3. पर पीसी को नजरअंदाज किया।
david.pfx

DOS प्रोग्रामिंग का एक बहुत कुछ था और 86 द्वारा मैं PVCS का उपयोग कर रहा था और नए जॉइनर्स की यूनिक्स पृष्ठभूमि थी, लेकिन जैसा कि यह बैंकिंग और वित्त में था, इसलिए हम आगे रहे
user151019

@मार्क: PVCS निश्चित रूप से 1985 तक उपलब्ध था, लेकिन अधिकांश ($ 000s) का उपयोग करने के लिए बहुत महंगा था। केवल बड़े सिस्टम से और पैसे जलाने वाले लोग इसका इस्तेमाल कर रहे होंगे।
david.pfx

-1

1993-1995 में मैं एक पेंशन प्रबंधक के साथ 15 डेवलपर्स के साथ SunOS में SPARCStation 20s और Sun IPX के साथ COS / C ++ विकास कर रहा था। हमारा कोडबेस एनएफएस माउंटेड डायरेक्टरी में था। प्रारंभ में हम कॉपी फ़ोल्डर वर्जनिंग कर रहे थे , लेकिन कुछ बिंदु पर हम एससीएससी में चले गए और कुछ टीमों ने आरसीएस का उपयोग करना शुरू कर दिया ।

1995 में मैं न्यूयॉर्क, लंदन और हांगकांग में C / C ++ विकास करने वाले 80+ डेवलपर्स के साथ एक और कंपनी में चला गया। हमने डेवलपमेंट माहौल को प्रबंधित करने के लिए मल्टी-साइट ऐड-ऑन के साथ क्लियरकेस का उपयोग किया ।

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


1
प्रश्न विशेष रूप से गैर-यूनिक्स माइक्रो सिस्टम के बारे में जानकारी के लिए पूछता है, लेकिन आपके द्वारा वर्णित सिस्टम (केवल उस समय) यूनिक्स वर्कस्टेशन पर उपलब्ध थे।
जूल्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.