ניהול גרסאות

מתוך ויקיפדיה, האנציקלופדיה החופשית

יש לך הודעות חדשות (השווה לגרסה הקודמת).

ניהול גרסאות (revision control ,version control או source control) משמעו מעקב אחר גרסאות מרובות של אותה יחידת מידע.

לרוב נעשה בזה שימוש בהנדסה ובפיתוח תוכנה לניהול פיתוח מתמשך של מסמכים דיגיטליים כדוגמת, קוד מקור של יישום, משאב אמנותי כמו שרטוט או דגם אלקטרוני, ומידע קריטי אחר שהעבודה עליו עשויה להתבצע בידי צוות אנשים. שינויים במסמכים אלו מזוהים באמצעות קידום מספר או קוד תווי אחר שמקושרים לגרסה ומבוטאים כ"מספר גרסה", או פשוט "גרסה". כל גרסה מקושרת היסטורית לאדם שביצע את השינוי. במודל פשוט של ניהול גרסאות, לדוגמה, למהדורה הראשונית של שרטוט מוצב מספר גרסה "1". כאשר מבוצע השינוי הראשון מקודם מספר הגרסה ל-"2" וכך הלאה.

כלי תוכנה לניהול גרסאות מזוהים יותר ויותר כחיוניים כמעט לכל פרויקט של פיתוח תוכנה.

מערכת מדיה ויקי, המשמשת ליצירה של מאגרי טקסט, מספקת ניהול שינויים מפורט: כל הגרסאות של כל מסמך נשמרות במאגר הנתונים, כולל השעה המדויקת שבה נוצרה כל גרסה וזיהוי היוצר, וניתן לזהות מה ההבדלים בין גרסה לגרסה.

[עריכה] סקירה

ניהול גרסאות הנדסה פותח מתהליכים פורמליים שמבוססים על מעקב אחר גרסאות של שרטוטים. במשתמע הייתה בבקרה זו היכולת לחזור לכל מצב קודם של העיצוב, למקרים שבהם שלב מתקדם של העיצוב נתקל במבוי סתום. באופן דומה, בהנדסת תוכנה, ניהול גרסאות הוא כל פרקטיקה שעוקבת ומאפשרת בקרה על השינויים שנעשים בקוד המקור. מפתחי תוכנה משתמשים לעתים בבקרת גרסאות להחזקת תיעוד וקובצי קונפיגורציה בנוסף לקוד מקור. בתאוריה, ניהול גרסאות עשוי להיות מיושם עבור כל סוג של תיעוד מידע. אך בפועל, הטכניקות והכלים המתוחכמים ביותר לניהול גרסאות כמעט ולא שימשו מחוץ לתחום פיתוח תוכנה, למרות שיכלו לספק יתרונות גם בתחומים רבים אחרים. עם זאת, הם מתחילים להיכנס לשימוש לשם מעקב אלקטרוני אחר שינויים בקובצי CAD, בדחקם יישום אלקטרוני "ידני" של ניהול גרסאות מסורתי.

כשתוכנה מפותחת ומופצת, שכיח באופן קיצוני מצב שבו גירסאות רבות של אותה התוכנה נמצאים בשימוש באתרים שונים, ושמפתחי התוכנה עובדים על עידכונים. באגים ושאר סוגיות שקשורות לתוכנה פעמים רבות קיימים רק בחלק מהגרסאות. לכן, במטרה לאתר ולתקן באגים, חיונית עבור מנפה השגיאות היכולת לאחזר ולהריץ גרסאות שונות של התוכנה וכך לקבוע באיזו גרסה/גרסאות הבעיה קיימת. אפשר גם שיהיה צורך לפתח במקביל שתי גרסאות של תוכנה, לדוגמה, כאשר בגרסה אחת תוקנו הבאגים אך חסרות בה תכונות חדשות, בעוד שבגרסה אחרת מצויות התכונות החדשות אך הבאגים טרם תוקנו.

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

[עריכה] מודלי אחסון

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

מודלי אחסון ביזוריים - לפני מספר שנים, מערכות כדוגמת TeamWare ,BitKeeper ו-GNU arch החלו להשתמש במודל מבוזר, שבו כל מפתח עובד עם מקום אחסון (repository) מקומי משלו והשינויים משולבים בין ה-repositories בשלב נפרד. מצב פעולה זה איפשר למפתחים לעבוד אף ללא חיבור רשת והוא אף איפשר למפתחים יכולות ניהול גרסאות מלאות, ללא צורך בקבלת הרשאות שמוענקים על ידי רשות מרכזית. אחד התומכים בניהול גרסאות מבוזר הוא לינוס טורבאלדס, מפתח לינוקס.

[עריכה] נעילת קובץ

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

חלק מהמערכות מונעות בעיות של גישה מקבילה (concurrent access), באמצעות נעילת קבצים, כך שרק למפתח אחד בזמן נתון יש גישה לכתיבה בהעתק של אותם קבצים ב-repository המרכזי. מערכות אחרות, כדוגמת Concurrent Versions System, מאפשרות למספר מפתחים לערוך את אותם קבצים באותו זמן. והן מספקות אמצעים למיזוג שינויים בשלב מאוחר. במערכות אלו, תפיסה של עריכה שמורה (reserved edit) יכולה לספק נעילת קובץ מפורשת לגישה בלעדית לכתיבה אליו. עם זאת יכולות המיזוג עדיין קיימות.

יתרונות נעילת קבצים מול חסרונותיה נתונים בוויכוח לוהט. מחד, נעילת קבצים יכולה לספק הגנה כנגד הקושי במיזוג שינויים מנוגדים. קושי שנוצר במקרים שבהם משתמש ביצע שינויים רדיקליים בחלקים רבים של קובץ גדול, או של מספר קבצים. אולם מאידך, כאשר קבצים נותרים נעולים באופן בלעדי למשתמש אחד זמן רב מדי, מפתחים אחרים עלולים להתפתות לעקוף את תוכנת ניהול הגרסאות ולשנות את הקבצים המקומיים למרות הנעילה, מה שעלול להוביל לבעיות רציניות יותר.

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

[עריכה] דחיסה

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

[עריכה] אוצר מילים שכיח

Repository: המחסן שבו נשמרים קובצי המידע ההיסטוריים והנוכחי, לרוב בשרת. לעתים משתמשים במילה depot.

Working copy: עותק מקומי של קבצים מה-Repository, בזמן או בגרסה מסוימים. כל העבודה הנעשית על קובצי ה-Repository מתבצעת ב-Working copy, ומכאן שמו.

Check-out: פעולה שיוצרת working copy מקומי מה-repository. פעולה זו יכולה להתבצע על גרסה מבוקשת או על הגרסה האחרונה. פעולה זו קרויה גם checkout או co.

Commit: מתרחש כאשר העתק של שינויים שנעשו ב-Working copy נכתבים ל-repository. לעתים קרוי check-in ,submit ,install, או ci.

Change: מייצג שינוי מסוים במסמך תחת ניהול גרסאות. הגרעיניות של מה שנחשב לשינוי משתנה בין מערכות ניהול גרסאות. קרוי גם diff או delta.

Change list: במערכות ניהול גרסאות שתומכות בטרנזקציה ל-Commit מרובה שינויים, changelist (או change set) מזהה קבוצת changes שנעשו ב-commit יחיד.

Update: מיזוג שינויים שנעשו ב-repository על ידי אנשים אחרים בצוות, לתוך ה-Working copy המקומי. קרוי גם sync.

Branch: סט קבצים תחת ניהול גרסאות עשויים להסתעף/להתפצל בנקודה בזמן, כך שמאותו זמן ואילך, שני עותקים של קבצים אלו עשויים להיות מפותחים באופן עצמאי ללא תלות זה בזה במהירויות שונות ובדרכים שונות. קרוי גם forked.

Merge

מיזוג שני סטים של שינויים, שנעשו בקובץ או בסט של קבצים, לתוך גרסה אחידה של קובץ או של סט קבצים זה. קרוי גם integration.

זה יכול לקרות כאשר משתמש אחד, שעובד על קבצים אלו, מבצע לתוך ה-working copy שלו updates עם שינויים שנעשו על ידי אחרים ונשמרו לתוך ה-repository. באופן הפוך, תהליך דומה יכול לקרות ב-repository כאשר משתמש מנסה לבצע check-in לשינויים שלו.
זה יכול לקרות לאחר הסתעפות (branched) של סט קבצים, כאשר בעיה שהייתה קיימת לפני ההסתעפות, תוקנה במסעף אחד וצריכה להיות ממוזגת לתך המסעף השני.
זה יכול לקרות כאשר מבקשים למזג ליחידה אחת, קבצים שפוצלו (branched) ופותחו באופן עצמאי במשך תקופה.

Revision: גרסה בתוך שרשרת של שינויים. קרוי גם version.

Tag: סימון קבוע לקבצים רבים בנקודת זמן חשובה. קבצים אלו בנקודת זמן זו יכולים כולם להיות מסומנים בשם בעל משמעות מובנת למשתמש. קרוי גם release או Label.

Import: פעולת העתקה של עץ תיקיות מקומי, שאינו working copy, לתוך ה-repository.

Export: פעולה דומה ל-check-out, מלבד זאת שעץ התיקיות המקומי שהיא יוצרת נקי ממטה-דטה של ניהול גרסאות, כזה שבו נעשה שימוש ב-working copy. לעתים קרובות נעשה בזה שימוש לקראת פרסום התוכן.

Conflict: קונפליקט מתרחש כאשר שני שינויים סותרים נעשו לאותו מסמך. מאחר שהתוכנה אינה נבונה דיה להחליט איזה מהשינויים הוא הנכון, המשתמש נדרש לפתור (resolve) את הקונפליקט.