سؤال

لقد قمت بالبرمجة لأكثر من 10 سنوات حتى الآن لنفس صاحب العمل والتحكم الوحيد في كود المصدر الذي استخدمناه على الإطلاق هو VSS.(آسف - هذا ما كان لديهم عندما بدأت).لم يكن هناك سوى عدد قليل منا.اثنان في الوقت الحالي وعادةً ما نعمل بمفردنا، لذلك عملت VSS بشكل جيد بالنسبة لنا.لذا، لدي سؤالان:1) هل يجب أن نتحول إلى شيء آخر مثل Subversion أو git أو TFS وما إلى ذلك، ما هو بالضبط ولماذا (من فضلك)؟2) هل أنا فوق كل أمل ومتجه إلى اللعنة الأبدية لأن VSS أفسدني (كما يقول جيف)؟

واو - شكرا لجميع الردود العظيمة!

يبدو أنني يجب أن أوضح بعض الأشياء.نحن متجر MS (شريك ذهبي) ونعمل في الغالب على VB وASP.NET وSQL Server وsharepoint وBiztalk.لقد حصلت على درجة علمية في علوم الكمبيوتر، لذا فقد قمت بتجميع x86 C وC++ على DEC Unix وSlackware Linux في "وقت خارج عن البال"...

ما يقلقني بشأن VSS هو أنني الآن أعمل على VPN كثيرًا وأداء VSS وأخشى أن يتم اختراق قاعدة بيانات VSS الإصدار 5+ y/o الخاصة بنا...هناك خدمة LAN من المفترض أن تعمل على تسريع الأمور، لكنني لم أستخدمها مطلقًا ولست متأكدًا من أنها تساعد في مكافحة الفساد - هل استخدم أي شخص خدمة VSS LAN؟(جديد مع VSS 2005)

هل كانت مفيدة؟

المحلول

ربما سأختار التخريب، لو كنت مكانك.أنا من عشاق Git تمامًا في هذه المرحلة، لكن Subversion له بالتأكيد بعض المزايا:

  • بساطة
  • وفرة من الأدوات القابلة للتشغيل البيني
  • مجتمع نشط وداعم
  • محمول
  • يتمتع بتكامل رائع مع Windows Shell
  • يتكامل مع الاستوديو المرئي (على ما أعتقد - ولكن بالتأكيد من خلال طرف ثالث)

يتمتع Git بالعديد والعديد من المزايا الأخرى، ولكن ما سبق هو ما يهتم به الأشخاص عند طرح أسئلة عامة مثل ما ورد أعلاه.

يحرر:الشركة التي أعمل بها الآن تستخدم خادم VisualSVN، وهو مجاني.إنه يجعل إعداد مستودع Subversion على خادم Windows أمرًا بسيطًا للغاية، وعلى العميل نستخدم TortoiseSVN (لتكامل Shell) وAnkhSVN لدعم Visual Studio.إنه أمر جيد جدًا، ويجب أن يكون من السهل جدًا حتى على مستخدمي VSS التقاطه.

تحرير اليوم الأخير:لذا.... بعد ما يقرب من ثماني سنوات، لا أوصي أبدًا بإصدار Subversion لأي شخص لأي سبب من الأسباب.أنا لا أتراجع حقًا، في حد ذاته, لأنني أعتقد أن نصيحتي كانت صحيحة في ذلك الوقت.ومع ذلك، في عام 2016، لم يحتفظ Subversion تقريبًا بأي من المزايا التي كان يتمتع بها على Git.تعد أدوات Git متفوقة (وأكثر تنوعًا) عما كانت عليه من قبل، وعلى وجه الخصوص، هناك GitHub وغيره من موفري استضافة Git الجيدين (BitBucket، Beanstalk، Visual Studio Online، خارج رأسي).يتمتع Visual Studio الآن بدعم Git الجاهز، وهو في الواقع جيد جدًا.توجد أيضًا وحدات PowerShell لتوفير تجربة Windows أصلية أكثر لمقيمي وحدة التحكم.يعد Git أسهل في الإعداد والاستخدام من Subversion ولا يتطلب مكون خادم.لقد أصبح Git منتشرًا في كل مكان مثل أي أداة منفردة، وسوف تخدع نفسك حقًا لعدم استخدامه (إلا إذا كنت تريد حقًا استخدام شيء غير Git).لا تسيئوا الفهم - هذا لا يعني أنني أكره Subversion، بل إنني أدرك أنها أداة من زمن آخر، مثل ماكينة حلاقة مستقيمة للحلاقة.

نصائح أخرى

يبدو أن SubVersion هو الفائز هنا.سأفعل لنفسك معروفًا وأستخدمه خادم فيسوال إس في إن.إنه مجاني وسيوفر عليك الكثير من مشاكل التثبيت.

إذا كنت معتادًا على الطريقة التي يعمل بها VSS، فراجعها (لا أقصد التورية) قبو Sourcegear.إنها طريقة ممتازة للانتقال بعيدًا عن VSS لأنها تأتي مع تكامل IDE وتدعم السحب/تسجيل الوصول، ولكن عندما تكون جاهزًا وتشعر بالراحة، يمكنك أيضًا الانتقال إلى نمط الالتزام بالتحديث والتحرير الموجود في البرمجة SVN.

إنه مجاني للمطورين الفرديين، ويعمل على IIS ومبني على .net، لذا يجب أن يكون مكدسًا مألوفًا إلى حد ما لتتمكن من التبديل إليه.

مهما فعلت، لا تتغير من أجل التغيير.

إذا كان يعمل لصالحك ولا تواجه مشكلات معه، فلا أرى أي سبب للتبديل.

بالنسبة لما يستحقه، يعد Perforce خيارًا محتملاً إذا التزمت حقًا بمستخدم واحد أو مستخدمين.تشير المستندات الحالية إلى أن لديك مستخدمين و5 عملاء دون الحاجة إلى البدء في شراء التراخيص.

قد يكون لديك أسباب للتبديل إلى القوة حسب سير العمل الخاص بك وإذا كنت بحاجة إلى التفرع بالطريقة التي يتم بها ذلك بالضرورة.نظرًا لعدم معرفتي المفرطة ببعض المنتجات الأخرى المذكورة هنا، لا أستطيع أن أخبرك بكيفية المقارنة في قسم الميزات لأشياء مثل التفرع، وما إلى ذلك.

إنه سريع، وكان قويًا للغاية بالنسبة لنا (أكثر من 300 مطور على قاعدة تعليمات برمجية عمرها أكثر من 10 سنوات).نقوم بتخزين العديد من المعلومات وكانت سريعة الاستجابة.مع وجود عدد قليل من المستخدمين، أشك في أنك ستواجه العديد من مشكلات الأداء على افتراض أن لديك أجهزة جيدة لخادمك.

بعد أن استخدمت VSS من قبل، أعتقد أنه يمكنك الحصول على العديد من الفوائد من نظام SCM أفضل بحيث يجب النظر في التبديل بغض النظر عما إذا كان لديك تلف أم لا.التفرع وحده قد يكون يستحق ذلك بالنسبة لك.يعد نموذج العميل/الخادم الحقيقي والواجهات الأفضل (برمجيًا وسطر الأوامر) من الأشياء الأخرى التي يمكن أن تساعد حقًا في تحسين سير عملك والمساعدة إلى حد ما في الإنتاجية.

باختصار، وجهة نظري في Perforce هي:

  • إنه سريع وموثوق تمامًا
  • الكثير من أدوات العملاء عبر الأنظمة الأساسية (windows، unix، mac، إلخ)
  • إنه مجاني لمستخدمين و 5 عملاء
  • يتكامل مع استوديو المطورين (والأدوات الأخرى)
  • لديه نظام متفرع قوي (قد يكون أو لا يكون مناسبًا لك).
  • لديه العديد من الواجهات القابلة للبرمجة (python، perl، Ruby، C++)

بالتأكيد YMMV - أنا فقط أقدم هذا البديل كشيء قد يكون من المفيد النظر فيه.

لقد بدأت مؤخرًا باستخدام زئبقي لبعض من أعمالي.إنه نظام موزع مثل Git ولكنه يبدو أسهل في الاستخدام ويبدو أنه مدعوم بشكل أفضل على نظام التشغيل Windows، وكان الأخير أمرًا بالغ الأهمية بالنسبة لي.

مع التحكم الموزع في التعليمات البرمجية المصدرية، يكون لدى كل مستخدم نسخة محلية كاملة من المستودع.إذا كنت الشخص الوحيد الذي يعمل في مشروع، كما تقول غالبًا، فقد يؤدي ذلك إلى تبسيط الأمور كثيرًا نظرًا لأنك تقوم فقط بإنشاء المستودع الخاص بك وتنفيذ جميع التزاماتك وما إلى ذلك.محليا.إذا كنت تريد الاستعانة بمطورين آخرين لاحقًا، فيمكنك فقط دفع المحتويات الكاملة لمستودعك - الإصدارات الحالية وكل التاريخ - إلى نظام آخر، إما على خادم مشترك أو مباشرة إلى محطة عمل مستخدمين آخرين.

إذا كنت تعمل فقط مع مستودع محلي، فتذكر أنك ستحتاج أيضًا إلى حل احتياطي لأنه لا توجد نسخة من كل التعليمات البرمجية الخاصة بك على خادم مشترك.

أعتقد أن Mercurial لديه الكثير من المزايا الأخرى مقارنة بـ Subversion، ولكن لديه جانب سلبي كبير تم ذكره بالفعل كنقطة إضافية لـ Subversion:هناك أ الكثير أدوات الطرف الثالث وعمليات التكامل للتخريب.نظرًا لأن Mercurial لم يكن موجودًا تقريبًا، فإن الاختيار أقل بكثير.في نظام التشغيل Windows، يبدو أنه يتعين عليك إما استخدام سطر الأوامر (اختياري) أو السلحفاة زئبق التكامل مع مستكشف Windows.

VSS أمر فظيع.ربما أقوم بتوجيه Spolsky (لست متأكدًا مما إذا كان قد قال هذا)، ولكن استخدام VSS هو في الواقع أسوأ من عدم استخدام التحكم بالمصادر على الإطلاق.على الرغم من اسمها، فإنه ليس كذلك آمن.يخلق الوهم بالأمان دون توفيره.

بدون VSS، من المحتمل أن تقوم بعمل نسخ احتياطية منتظمة من التعليمات البرمجية الخاصة بك.مع VSS، ستفكر، "حسنًا، إنه بالفعل تحت التحكم بالمصادر.لماذا تهتم بالنسخ الاحتياطي؟" عظيم حتى ذلك يفسد قاعدة التعليمات البرمجية بأكملها وتخسر ​​كل شيء.(وهذا حدث بالمصادفة في الشركة التي كنت أعمل فيها).

تخلص من VSS بأسرع ما يمكن وانتقل إلى حل حقيقي للتحكم في المصدر.

لا تقلق بشأن إفساد VSS لك، ولكن تقلق بشأن إتلاف VSS لبياناتك.ليس لديها سجل جيد في هذا القسم.

قم بالنسخ الاحتياطي بشكل متكرر إذا لم تقم بالتبديل إلى نظام مختلف للتحكم في الإصدار.يجب أن تتم عمليات النسخ الاحتياطي يوميًا حتى مع أنظمة إدارة سلسلة التوريد الأخرى، ولكنها ذات أهمية مضاعفة مع VSS.

أحب استخدام Subversion لمشاريعي الشخصية.يمكنني أن أذهب إلى قائمة الميزات وأتظاهر بأنها تجلب الكثير إلى الطاولة لا تفعله أنظمة التحكم بالمصادر الأخرى، ولكن هناك الكثير من الميزات الجيدة والاختيارات الصحيحة هي في الواقع مسألة أسلوب.إذا قمت بتسجيل الوصول بعد كل تغيير صغير (أي.تسجيل وصول واحد لكل تغيير في الوظيفة)، فيمكن للعديد من الأشخاص العمل على نفس الملف المصدر مع انخفاض خطر حدوث تعارضات دمج في أي شيء عمليًا لكن VSS (لم أستخدم VSS منذ سنوات ولكن على ما أتذكر، لا يمكن إلا لشخص واحد فقط العمل على ملف في كل مرة.) إذا لم يحدث هذا لك أبدًا، أشعر أن أفضل مسار للعمل هو استخدام ما تعرفه.يعد VSS أفضل من عدم وجود تحكم بالمصادر على الإطلاق، لكنه يبدو مقيدًا بالنسبة لي هذه الأيام.

لا أعتقد أنك فقدت الأمل لأنك تتساءل عما إذا كان من الأفضل التبديل؛أنت خارج الأمل عندما تكون الإجابة واضحة وتتجاهل الأدلة.

حتى لو لم تقم بتغيير أنظمة التحكم بالمصادر، فيجب عليك اختيار نظام مثل SVN أو git وقضاء بضعة أسابيع في القراءة عنه وإنشاء مشروع صغير باستخدامه؛فهو يساعد دائمًا على شحذ المنشار.

أنا لا أتفق مع الأشخاص الذين يقولون إنه إذا لم تكن لديك مشاكل فمن الأفضل ألا تتغير.

أعتقد أن SCM هي بعض التخصصات التي يجب على المطور الجيد أن يعرفها جيدًا، وبصراحة، حتى إذا كنت تتقن VSS فإنك تقوم فقط بتجربة جزء صغير من المزايا التي يمكن أن تقدمها لك أداة SCM الجيدة واستراتيجية SCM لك ولفريقك.

من الواضح أن تقييم البدائل واختبارها أولاً في بيئة غير إنتاجية.

في العمل نستخدم Subversion مع TortoiseSVN - يعمل بشكل جيد جدًا ولكنه يختلف فلسفيًا عن VSS (لا يمثل مشكلة حقًا إذا كنت أنت فقط ولكن الأمر يستحق أن تكون على دراية به).تعجبني حقًا حقيقة أن المستودع بأكمله يحتوي على رقم مراجعة.

لو كان لدي خيار حر، ربما كنت سأختار القبو، لكن في ذلك الوقت لم يكن لدي أي ميزانية.

أنا أنظر إلى الأشياء للاستخدام الشخصي.هناك أسباب لاستخدام التخريب وأسباب لاستخدام شيء مختلف تمامًا.البدائل التي أفكر فيها هي Vault (كما كان من قبل، مجاني للاستخدام الفردي) وBazaar.لقد اضطررت إلى رفض GIT لأنني، بلا خجل، شخص يعمل بنظام Windows والآن GIT ليس كذلك.

الطبيعة الموزعة لـ GIT وخيار تسجيلات الوصول الخاصة/المؤقتة (بافتراض أنني فهمت ما قرأته) يكون جذابة - ومن هنا نظرتي إلى البازار.

تحديث: لقد قمت بمزيد من البحث واللعب واخترت بالفعل Mercurial للاستخدام الشخصي، والتثبيت المتكامل مع TortoiseHg يجعل الأمور بسيطة للغاية ويبدو أنه يحظى بتقدير كبير.ما زلت أحاول معرفة كيفية فرض مرآة سحرية تلقائية للالتزامات على الخادم ويبدو أن هناك بعض القيود البسيطة على وظيفة التجاهل ولكنها تؤدي المهمة بشكل جيد حتى الآن...

مورف

أود أن أقول التمسك بما يناسبك.ما لم تكن لديك مشكلات مع VSS، فلماذا التبديل؟يعتبر Subversion منتفخًا، على الرغم من صعوبة البدء في استخدامه.TFS أفضل بكثير من VSS، على الرغم من أنها مكلفة إلى حد ما لمثل هذا الفريق الصغير.لم أستخدم git لذا لا يمكنني التحدث إليه حقًا.

لقد استخدمت vss لسنوات حتى التحول إلى svn منذ حوالي عامين.كانت أكبر شكواي بشأن vss هي ضعف أداء الشبكة (قد يتم حل هذه المشكلة الآن) والقفل المتشائم للملفات.حل svn كلا الأمرين، وهو سهل الإعداد (أستخدم خادم Collabnet وعميل tortoisesvn، على الرغم من وجود مكونين إضافيين جيدين للاستوديو المرئي:visualsvn - تجاري، وankhsvn - مفتوح المصدر)، سهل الاستخدام والإدارة، وموثق جيدًا.

من المغري أن نقول "إذا لم يكن مكسورًا فلا تقم بإصلاحه" ولكنك ستتعلم أداة أكثر حداثة للتحكم في المصدر، وربما الأهم من ذلك، طرقًا جديدة لاستخدام التحكم في المصدر (على سبيل المثال.المزيد من التفريع والدمج بشكل متكرر) التي ستدعمها الأداة الجديدة.

إذا كان لديك شخصين فقط، وكنت تعمل في الغالب بشكل مستقل، فسوف تمنحك git قدرًا أكبر من المرونة والقوة وستكون الأسرع في العمل معه.

ومع ذلك، فمن الألم في المؤخر للاستخدام.باستخدام VSS، من الواضح أنك تبرمج لنظام التشغيل Windows - إذا كنت تقوم بأشياء Win32 API في لغة C، فستكون git بمثابة منحنى تعليمي ولكنها ستكون مثيرة للاهتمام للغاية.

إذا كانت أعماق معرفتك تمتد فقط إلى ASP وVisual Basic، فما عليك سوى استخدام Subversion.المشي قبل أن تتمكن من الركض.

** أنا لا أحاول أن أقول إذا كنت تعرف VB فقط فأنت غبي أو أي شيء من هذا القبيل، ولكن يمكن أن تكون هذه البوابة صعبة للغاية ومن الصعب إرضاءها في الاستخدام (إذا كنت قد استخدمت WinAPI في لغة C، فأنت تعرف كل شيء عن الانتقاء والدقة) Finicky)، وقد ترغب في الحصول على مقدمة تدريجية لـ SCM أكثر مما توفره git

إذا كنت رجلًا واحدًا ومتجرًا صارمًا لشركة Microsoft، إذن مصدر جير قبو هو بالتأكيد مرشح رئيسي للتبديل أيضًا.

سمات:

  • مجاني لمستخدم واحد، رائع بالنسبة لك
  • فهو يستخدم SQL Server لواجهته الخلفية، وبالتالي فإن موثوقية البيانات كبيرة
  • يحتوي على تسجيلات وصول ذرية، ويتم ترتيب جميع الملفات التي يتم تسجيلها في نفس الوقت في مجموعة وتسمى مجموعة التغييرات.
  • التكامل فيجوال ستوديو.
  • لديه أداة للاستيراد من SourceSafe، وبالتالي يمكنك الاحتفاظ بالسجل الخاص بك
  • يتواصل العميل مع الخادم عبر HTTP، وبالتالي يمكن إعداد الوصول إلى المصدر خارج المكتب عن بعد بسهولة شديدة ويعمل بشكل جيد، لأنه ينقل فقط دلتا التغييرات التي يتم إرسالها واستلامها.يمكنك استخدام SSL لتأمين الاتصال.

سأعتبر هذا بالتأكيد خيارًا.

إذا كنت تريد دورة حياة كاملة في حزمة واحدة، فربما تريد إلقاء نظرة على Visual Studio Team System.إنه يتطلب خادمًا، ولكن يمكنك الحصول على "Action Pack" من MS الذي يتضمن جميع التراخيص التي تحتاجها لـ "Team Foundation Server Workgroup Edition" من مركز الشركاء.

وبهذا ستحصل على تتبع الأخطاء والمخاطر والمشاكل بالإضافة إلى العديد من الميزات الأخرى :)

  • التحكم بالمصدر
  • تتبع عناصر العمل (المتطلبات والأخطاء والقضايا والمخاطر والمهام)
  • إعداد التقارير عن بيانات مشروعك (تتبع عناصر العمل والبناء والتحقق والمزيد في qube واحد)
  • تحليل الكود
  • وحدة التجارب
  • اختبار الحمل
  • تحليل الأداء
  • البناء الآلي
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top