ओपनसोर्स प्रोजेक्ट में संस्करण नियंत्रण का उपयोग शुरू करने के लिए मेरे लिए सबसे अच्छा तरीका क्या है?


10

यह सुझाव दिया गया था कि मैं अपने प्रोजेक्ट को उसके आकार और कौशल की कमी के कारण खुला स्रोत लेता हूं, इसलिए मैंने Google कोड की जाँच की, और एक प्रोजेक्ट बनाना शुरू किया और अब मुझसे पूछ रहा है कि क्या मुझे प्रोजेक्ट Git, Mercurial, या Subversion चाहिए कोड होस्टिंग।

मुझे यह भी नहीं पता है कि कोड होस्टिंग क्या है, और एक खोज ने मुझे इन सभी चीजों के बीच बहस के साथ और अधिक भ्रमित कर दिया, और यह और भी बदतर बना दिया जाता है क्योंकि Google कोड मुझसे पूछ रहा है कि मुझे किस प्रकार का लाइसेंस चाहिए।

मुझे लगता है कि मैं बिल्कुल समझ नहीं पा रहा हूं कि खुले स्रोत का वास्तव में क्या मतलब है, क्या कोई बहुत जल्दी एक आम आदमी की चीट शीट बना सकता है कि यह सब क्या है? बहुत सराहना की।

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



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

1
यह वास्तव में 2 प्रश्न हैं, और दोनों शायद डुप्लिकेट हैं। stackoverflow.com/questions/2303136/… , और stackoverflow.com/questions/3859/…
sylvanaar

2
"कौशल की कमी" कुछ खुला स्रोत बनाने के लिए एक भयानक कारण की तरह लगता है। यदि आपके पास एक शानदार विचार है, लेकिन तकनीकी कौशल की कमी है, तो हो सकता है। मैं तब तक खुला स्रोत नहीं जाऊंगा जब तक कि मुझे एक तकनीकी रूप से कुशल साथी नहीं मिला जो कोड के पहले कट का उत्पादन करने के लिए प्रतिबद्ध है, और जो खुला स्रोत जाना चाहते हैं।
ट्रिपल

ट्रिपलआई क्या आप किसी नेटवर्क या उस प्रकृति की किसी चीज़ के बारे में सुझाव देने में सक्षम होंगे जहाँ मैं संभवतः किसी के साथ साझेदारी कर सकता हूँ?
नाथन

जवाबों:


7

मैं इस तरह से कोड की मेजबानी क्यों करूंगा?

ओपन सोर्स सॉफ्टवेयर डेवलपमेंट का एक महत्वपूर्ण बिंदु सोर्स कोड को साझा करना है। इसे करने के कई तरीके हैं, जैसे कि वेब या एफ़टीपी सर्वर पर टार / जिप फाइलें डालना। Google कोड (या sourceforge.net, gitorious.org, bitbucket.org, और कई अन्य) जैसी सेवाएं इस उद्देश्य के लिए अपने स्वयं के सर्वर चलाने की आवश्यकता को दूर ले जाती हैं।

और क्या इसका मतलब मुझे अपनी वर्तमान होस्टिंग से हटना होगा, या यह एक पूरी तरह से अलग तरह की होस्टिंग है?

ये सेवाएं सामान्य-उद्देश्य वेब होस्ट नहीं हैं, लेकिन बहुत विशिष्ट सेवाएं चलाती हैं। वे किसी उत्पाद का मुखपृष्ठ नहीं होते, बल्कि एक डेवलपर डैशबोर्ड होते हैं।

गूगल कोड के साथ आपको मिलता है

  • एक विकी
  • एक बगट्रैकर
  • नियमित फ़ाइल डाउनलोड स्थान
  • एक संस्करण नियंत्रण सर्वर

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

जब मैं अपनी साइट को खुला स्रोत बनाता हूं, तो मेरे पास क्या अधिकार हैं,

यह एक मुश्किल सवाल है, क्योंकि यह उस देश के कानून पर निर्भर करता है जहां आप रहते हैं।

मैं क्या अधिकार देता हूं।

यह उस लाइसेंस पर निर्भर करता है जो आप उत्पाद को देते हैं। यह मालिकाना खुले स्रोत (पीजीपी के बारे में सोच) से जा सकता है जहां उपयोगकर्ता मूल रूप से कोड के साथ कुछ भी नहीं कर सकता है, पैमाने के दूसरे छोर पर सार्वजनिक डोमेन है, जहां हर कोई जो चाहे कर सकता है।

यह कैसे काम करता है, क्या लोग आते हैं और मुफ्त में मुझ पर कोड फेंकते हैं?

ऐसा होने की संभावना बहुत कम है, क्योंकि आपके उत्पाद को अन्य डेवलपर्स को आकर्षित करने के लिए पर्याप्त लोकप्रियता की आवश्यकता होती है।

[...] और अब यह मुझसे पूछ रहा है कि क्या मैं चाहता हूं कि प्रोजेक्ट में Git, Mercurial या Subversion कोड होस्टिंग हो।

ये तीन अलग-अलग संस्करण नियंत्रण प्रणालियां हैं, जहां तोड़फोड़ एक केंद्रीकृत है, जबकि गिट और मर्क्यूरियल वितरित किए जाते हैं।

धार्मिक युद्ध हैं जिनके बारे में किसी को उपयोग करना है, लेकिन मुख्य बिंदु एक का उपयोग करना है। अधिक जानकारी के लिए http://martinfowler.com/bliki/VersionControlTools.html देखें ।

जब तोड़फोड़ का चयन करने के लिए:

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

Ur मर्क्यूरियल के लिए लॉक एक्सटेंशन है, लेकिन मुझे इसके साथ कोई अनुभव नहीं है, और अगर यह प्रयोग करने योग्य नहीं है, तो मैं नहीं कह सकता।

जब आपको पूर्व सुविधाओं की आवश्यकता नहीं होती है, तो Mercurial या Git का उपयोग करना बेहतर होता है। दोनों में तोड़फोड़ के निम्नलिखित फायदे हैं:

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

    • लेकिन चूंकि कोई भी इन संशोधनों की जांच नहीं करता है, इसलिए यह सुविधा व्यावहारिक रूप से प्रभावी नहीं है

9

कोड होस्टिंग ठीक यही है - कहीं न कहीं अपने कोड को होस्ट (या रखना) करना।

Git, Mercurial और Subversion सभी स्रोत नियंत्रण उपकरण हैं जिनका उपयोग आप अपने कोड इतिहास को प्रबंधित करने के लिए करते हैं। Git और Mercurial वितरित सिस्टम हैं जबकि Subversion एक अधिक पारंपरिक सर्वर आधारित सेटअप है।

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


6

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

ओह, और जब आप होस्ट करने के लिए तैयार होते हैं, तो आप Google कोड, बिटबकेट , जीथब ( इस उत्कृष्ट एक्सटेंशन की मदद से ) या अन्य का उपयोग कर सकते हैं।


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

3

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

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


2

तोड़फोड़ करना सबसे आसान विकल्प होगा क्योंकि यह वीसीएस है। Git और Mercurial DVCS सिस्टम हैं। वे अधिक आधुनिक और अधिक शक्तिशाली हैं, लेकिन समझने में मुश्किल हैं। TortoiseSVN या TortoiseHG (Mercurial उर्फ ​​HG के लिए) जैसे फ्रंट-एंड का उपयोग करना वास्तव में मदद करता है।

यदि आपका सॉफ़्टवेयर एक स्टैंड-अलोन प्रोग्राम है, तो आप GPL का उपयोग कर सकते हैं या वास्तव में इसे BSD लाइसेंस के साथ खोल सकते हैं। यदि आपकी परियोजना एक पुस्तकालय है जिसे कोई और LGPL या फिर BSD के उपयोग से लिंक करेगा; लेकिन GPL का उपयोग न करें।

[संपादित करें]

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


1
आप क्यों कहते हैं कि svn सबसे आसान है? कृपया इस कथन को सही ठहराएं।

1
@ रीचर्ड: मुझे लगता है कि इसका मतलब है कि मूल उपयोग के लिए इसे स्थापित करना और उपयोग करना थोड़ा आसान है, कम से कम मैं उस धारणा से सहमत हूं। मैं इस विचार से असहमत हूं कि आपके पुस्तकालय को जीपीएल का उपयोग नहीं करना चाहिए, यह वास्तव में एक राजनीतिक रुख है।
Kheldar

लाइब्रेरी के लिए GPL का उपयोग करें यदि आप इसके उपयोग पर कुछ प्रतिबंध लगाना चाहते हैं। यदि आप कम प्रतिबंध लगाना चाहते हैं तो LGPL का उपयोग करें।
कीथ थॉम्पसन

0

मुझे ऐसा लगता है कि जब तक सबसे यहाँ के लोग जवाब दे रहे हैं कि कैसे , कोई वास्तव में उत्तर दिया है क्यों अपने प्रश्न में।

मेरे द्वारा अनुभव की गई पहली ओपन सोर्स परियोजनाओं में से एक शानदार फ्रैक्टिन प्रोजेक्ट था, यह स्टोन सूप ग्रुप द्वारा विकसित किया गया था जो पुराने स्टोन सूप लोक कहानी से प्रेरित थे ।

मेरे लिए, यह किसी भी स्टालमैन शेत या मूल GNU मैनिफेस्टो की तुलना में खुले स्रोत की भावना को बेहतर बनाता है । यह उस समुदाय की ताकत के लिए एक वसीयतनामा है कि कोड के विशेष रूप से खाना पकाने के बर्तन के नीचे आग जलाने के 23 साल बाद भी फ्रैक्टिन को विकसित किया जा रहा है


0

ओपन सोर्स का मतलब है कि कोई भी आपके कोड को पढ़, कॉपी, संशोधित और वितरित कर सकता है। आगे बढ़ने से पहले आपको इसके निहितार्थों के बारे में अच्छी समझ होनी चाहिए। शायद आपको एक किताब पढ़नी चाहिए या कम से कम इस विषय पर और / या http://opensource.org/ पर विकिपीडिया लेखों को ब्राउज़ करना चाहिए जब तक आपको लगता है कि आपके पास अवधारणा की समझ नहीं है।

(ओ'रिली पुस्तक ओपन सोर्स http://oreilly.com/openbook/opensources/book/index.html सहायक है, लेकिन शायद आप जो खोज रहे हैं, ठीक नहीं है।)

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


0

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

वैसे भी इस कोड को अन्य लोगों द्वारा इसे प्राप्त करने के लिए पुन: प्राप्य होना चाहिए।

अपने कोड को सार्वजनिक ऑनलाइन रिपॉजिटरी जैसे कि GitHub पर ले जाना सबसे अच्छा तरीका है। पहले, आपका कोड अब जनता के लिए सुलभ है। फिर, चूंकि ऐसी सेवाएं भी संस्करण नियंत्रण प्रदान करती हैं, इसलिए आपका कोड परियोजना संगठित है। आप अपने और अन्य लोगों द्वारा किए गए परिवर्तनों का ट्रैक रख सकते हैं। चूंकि यह परियोजना को अन्य अलग-अलग परियोजनाओं में विभाजित करने (अलग करने) की अनुमति देता है, इसलिए आप अपने कोड से बने सभी अलग-अलग संस्करण का ट्रैक रख सकते हैं।

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

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

यह चीजों को करने के सामान्य मानक, सामान्य अभ्यास की तरह है।

कुछ लिंक जो आपको खुले स्रोत को समझाने के लिए उपयोगी हो सकते हैं:


-6

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

स्रोत (डीवीसीएस की लोकप्रियता के बारे में):

/programming/tagged/git ~ 10k प्रश्न /programming/tagged/mercurial ~ 3k प्रश्न

http://www.googlefight.com/index.php?lang=en_GB&word1=git&word2=mercurial

11700000 परिणाम बनाम

1580000 परिणाम

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


7
मर्क्यूरियल मालिकाना नहीं है ... यह गेट के रूप में बिल्कुल खुला स्रोत है!
क्रिश्चियन स्पैच

4
आंशिक रूप से गलत तर्कों के साथ फैनबॉय उत्तर।
ओबेन सोन

1
"सबसे अधिक उपयोग किया जाता है" - कृपया उस जानकारी के अपने स्रोत का संदर्भ प्रदान करें।
सिल्वानार

क्षमा करें लोग .. यह सिर्फ चीजों के बारे में मेरी धारणा है: मुझे लगता है कि Git का उपयोग Mercurial की तुलना में अधिक किया जाता है, और मुझे पता है कि SVN पुराना है, धीमा है और केंद्रीकृत है ... मुझे आश्चर्य है कि क्या आपकी टिप्पणी मेरे तथाकथित से कम फैनबॉय-कमेंट्स हैं fanboy-जवाब। चलो, git हब git का उपयोग करता है, Linux कर्नेल git का उपयोग करता है, मेरे विभाग की प्रत्येक परियोजना git का उपयोग करती है ...
Pedro Rolo

2
शायद Git के बारे में प्रश्नों की बहुतायत भी बताती है कि इसका उपयोग करना अधिक कठिन है? कुछ लोगों ने इसी तरह के डेटा का उपयोग किया है जब जांच की गई थी कि वेब विकास ढांचे सबसे 'लोकप्रिय' थे जहां एक ही बिंदु उठाया गया था (अशुद्धियों पर टिप्पणी)।
टिम पोस्ट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.