סקר Source Control

choo

Active member
הוא סובל מבורות, לא דתיות (ואצלנו - git)

רוב האנשים שעבדו על פרוייקט מספיק מורכב עם cvs - אחרי כמה חודשים עם git או mercurial לא יבינו איך הם הסתדרו עם ה-branches הגרועים של cvs. אני לא מדבר על ענייני הביזור - אני מדבר על ענייני הניהול.

מה שכן - חשוב שיהיה מישהו אחד עם נסיון משמעותי בעבודה עם git שיוכל להגדיר מודל עבודה *תקין* וגם *יעיל* ושגם מתאים למודל האירגוני - אחרת ההתחלה עלולה להיות קשה (או מאוד קשה). במובן הזה, שמעתי שמועה שעבודה עם mercurial תהיה קלה יותר.
 

zaske

New member
מנסיוני עם cvs, svn ו git

cvs גם גרוע יותר מsvn
לצערי שכחתי כבר למה, אבל היה משהו מאוד מרגיז שם. לא זוכר, אולי הקטע של locks על הקבצים? אולי משהו שקשור לספריות (ולא לקבצים) - אחד מהנושאים האלה.
 

choo

Active member
ב-cvs לא צריך locks

svn הוא פשוט "עוד מאותו דבר". אמרו "יש בעיות כאלו וכאלו ב-cvs - בואו נשפר", ושיפרו נקודות שונות. למעשה, הם שמרו על תאימות מבחינת ממשק המשתמש.

באו אנשי bitmover ואמרו - בואו נעבור למודל שונה לגמרי, שיפתור את הבעיות היסודיות של cvs ודומותיה.

באו אנשי קוד פתוח, שנתנו להם להשתמש ב-bitkeeper ואז לקחו להם אותו, ואמרו "בואו נממש דמוי-bitkeeper בתור קוד פתוח" - ויש לך את git, למשל.

הבעיה הבסיסי ב-cvs היא שאין אובייקט של commit - אלא אוסף של קבצים ש"נדחפים יחדיו" לגמרי במקרה. זה אומר שאם שני אנשים דוחפים ביחד - לא מובטח סדר ולא אטומיות. זה אומר שה-repository מנוהל ברמה של קבצים ולא של patches (ה-patches שם - אבל אינם "אזרחים מהשורה הראשונה"). זה אומר שכל פעם שצריך לבצע merge - צריך לאמר לכולם "לא לגעת בשרת המרכזי" - ואף אחד אחר לא יכול לעשות commit לשם. זה אומר שניהול merge בין branches לוקח הרבה זמן (אני זוכר שעות רבות שהושקעו על merge בין שני branches בפרוייקט של 4.5 מפתחים - שעבדנו עליו כ-3 שעות. ב-git עושים merge מספר פעמים ביום, ושמירה על קוד מסונכרן בין גרסה נוכחית לגרסה עתידית נעשה כמעט טריויאלי. ב-cvs בגלל שזה היה כרוך ביותר עבודה, היו דוחים את ה-merge עד לרגע האחרון - ואז היה "מתפוצץ" בלון.

בנוסף, ב-git כל אחד יכול ליצור לעצמו branch כאוות נפשו. ב-cvs (וגם ב-svn) - רק האדמין יכול לעשות את זה.

יש עוד מגוון של תכונות שמודל ה-patch set של git מאפשר, שפשוט לא ניתן לבצע במודל כמו של cvs ו-svn.
 

יוספוס11

New member
כן. זה מוציא אותי מדעתי.

תאר לך Build Machine שצריך להוציא TAG מסויים מ-CVS כדי לבנות. מכונה שאמורה לעשות את זה בצורה אוטומטית, אבל כל שני וחמישי, בלי הודעה מוקדמת, ה-Checkout פשוט "נתקע", לא זז. תקוע על איזה קובץ - בכל פעם קובץ אחר וצריך פשוט להתחיל את זה מהתחלה - ואז לאחר מספר רנדומלי של נסיונות, ה-Checkout עובר בהצלחה.
 

izackv

New member
לתוכניתן אחד, שעובד על גרסה אחת

כולם טובים.
אבל כשנכנסים ליער (ענפים) - פתאום מגלים שבחלק מהתוכנות פיצול ואיחוד של ענפים אטרקטיבי כמעט כמו טיפול שורש בלי הרדמה.

אז מסתבר מה באמת חסר ב CVS ולמה GIT ושאר חבריו המבוזרים כאלה מוצלחים.
כמובן, כל עוד שומרים על נהלים פיתוח נכונים.

וזה בלי להתייחס לעניינים פעוטים כמו הסיכוי לאבד התקנת CVS או SVN בגלל תקלות חומרה ובעייה בגיבויים לעומת העובדה שבכלים מבוזרים הסיכון הזה כמעט ולא קיים.
וכן, יצא לי פעם לשבת על SVN שנדפק ולנסות להציל אותו.
 
היום ב git לפניו השתמשו פה ב svn

בחברה הקודמת שלי כיום עובדים עם svn, שהחליף את cvs שהיה בשימוש עד לפני מספר שנים.
 
Hg
עם ה-


 

izackv

New member
git

עצוב, אבל CVS היא לא באמת דת.
יותר כמו כת השטן למתקדמים.

אני די מתחבר למוטו הפיתוח של git שאמר ש:
"בכל מקום שיש ספק איך לעשות משהו, צריך לבדוק איך זה יושם ב CVS וליישם בדיוק הפוך"

יש כמובן כמה בעיות עם GIT. בעיקר כשמתעקשים לעבוד איתה בצורה לא נכונה.
צריך גם להבין קצת יותר לעומק את ההבדלים בין ניהול תצורה מבוזר לכזה מרכזי.
 

zaske

New member
לדעתי ל git יש learning curve יותר גבוה

ואחרי זה אתה לא מבין איך חיית בלי זה.
 

טלד

New member
GIT

לצערי, עוד לא נתקלתי בSource Control שאני יכול להגיד בפה מלא שהוא גם טוב וגם נוח לשימוש.

ל-GIT יש עקומת למידה הרבה יותר מדי ארוכה, אבל אחרי שעברתי אותה הוא כנראה הפתרון הכי סביר שקיים כרגע.
 

user32

Well-known member
מנהל
לצערי SVN

אין לי מספיק זמן להשקיע בשביל ללמוד לעבוד עם GIT כמו שצריך וכרגע אין לי לקוח שעובד עם GIT כך שלא יוצא לי לנסות. הצוותים קטנים מדי בשביל שסורס קונטרול יהיה משהו קריטי לפרוייקט (כשיש 1-3 אנשים שעובדים על אותו קוד ויש רק branch אחד SVN מספיק בהחלט).
 
למעלה