יש לכם blacklist של דברים שלא נכנסים לsource control?
- פותח הנושא TakeCtrl
- פורסם בתאריך
כלל מוכר ומוצדק
למה שקבצי IDE יהיו משותפים לכולם? אנשים עובדים עם IDE שונים, מערכות הפעלה שונות, מבנה תיקיות שונה, ואז איזה חכם מחליט להעלות קובץ IML וכולם צריכים לשבור את הראש בכל עדכון איך למזג בצורה כזאת שהתצורה הרגילה שלהם תשמר ובלי שיהיה קונפליקט.
קבצים מקומפלים אני משתדל לא להכניס. יש פתרון כמעט לכל מצב בהקשר הזה.
למה שקבצי IDE יהיו משותפים לכולם? אנשים עובדים עם IDE שונים, מערכות הפעלה שונות, מבנה תיקיות שונה, ואז איזה חכם מחליט להעלות קובץ IML וכולם צריכים לשבור את הראש בכל עדכון איך למזג בצורה כזאת שהתצורה הרגילה שלהם תשמר ובלי שיהיה קונפליקט.
קבצים מקומפלים אני משתדל לא להכניס. יש פתרון כמעט לכל מצב בהקשר הזה.
תכל'ס איזו תקורה יש לכם?
אצלנו עובדים מספר אנשים עם XCODE ואין בעיה מיוחדת במרג'ים (GIT).
הגדרות הבילד זהות לכל מי שעובד על אותו הפרויקט, אין סיבה שאחד יקמפל אחרת מהשני.
אם אני מדליקה איזה דגל מיוחד בקומפילציה לצורכי דיבאג, אני זוכרת לכבות אותו לפני פוש. זה נכון שעקרונית יכולות להכנס ככה בעיות וצריך להזהר, אבל בפועל זה לא ממש קורה (לא קרה מעולם עד היום לפחות).
 
 
אצלנו עובדים מספר אנשים עם XCODE ואין בעיה מיוחדת במרג'ים (GIT).
הגדרות הבילד זהות לכל מי שעובד על אותו הפרויקט, אין סיבה שאחד יקמפל אחרת מהשני.
אם אני מדליקה איזה דגל מיוחד בקומפילציה לצורכי דיבאג, אני זוכרת לכבות אותו לפני פוש. זה נכון שעקרונית יכולות להכנס ככה בעיות וצריך להזהר, אבל בפועל זה לא ממש קורה (לא קרה מעולם עד היום לפחות).
 
 
שינויי סכימה עושים לעיתים נדירות מאוד
מחיקה/הוספה של קבצים לפרויקט לרוב עוברת את המרג' האוטומאטי. לפעמים יש קונפליקטים אבל לא הרבה, וקלים לפתרון. אם אתם בפרויקט חדש לגמרי אז אני יכולה להבין שבאמת יהיו יותר בעיות כאלו.
 
בעיה משמעותית יותר היא כשמשנים בו"ז את אותו XIB, את זה המרג' תמיד ידפוק - ואפילו ידנית לפעמים זה קשה מאוד למרג'ג'. אנחנו משתדלים לא לעשות את זה (וכיוון שאנחנו בינתיים מעט מפתחים ויושבים יחד זה לא קשה).
 
אני לא יודעת כמה אנשים אתם על הפרויקט, אבל מציעה לכם גם פשוט להמנע מלעבוד בו"ז על סכימה, אין בזה לרוב צורך אמיתי (מה אתם כבר משנים שם כל כך הרבה?)
 
מחיקה/הוספה של קבצים לפרויקט לרוב עוברת את המרג' האוטומאטי. לפעמים יש קונפליקטים אבל לא הרבה, וקלים לפתרון. אם אתם בפרויקט חדש לגמרי אז אני יכולה להבין שבאמת יהיו יותר בעיות כאלו.
 
בעיה משמעותית יותר היא כשמשנים בו"ז את אותו XIB, את זה המרג' תמיד ידפוק - ואפילו ידנית לפעמים זה קשה מאוד למרג'ג'. אנחנו משתדלים לא לעשות את זה (וכיוון שאנחנו בינתיים מעט מפתחים ויושבים יחד זה לא קשה).
 
אני לא יודעת כמה אנשים אתם על הפרויקט, אבל מציעה לכם גם פשוט להמנע מלעבוד בו"ז על סכימה, אין בזה לרוב צורך אמיתי (מה אתם כבר משנים שם כל כך הרבה?)
 
מצאתי מקור נהדר לקבצי דוגמה כאלה:
אומנם אלה הם ספציפית ל-git, אבל אפשר ללמוד מהם, ולהמיר אותם לכל SC:
https://github.com/github/gitignore
 
בגדול, חשוב להימנע מהכללת תוצרים בינאריים. זה ינפח את המאגר לשווא וגם יראה שינויים היכן שאין באמת כאלה (לא שינית כלום בקוד, אבל ה-time stamp של ה-build השתנה).
 
לגבי קבצי סביבת פיתוח - אם אתה ורק אתה עובד על הפרויקט ממחשב בודד, אז ניחה.
ברגע שיש עוד אנשים, זו צרה צרורה.
לרוב, סביבות פיתוח מכניסות נתיב אובסולוטי לחלק מקבצי הקונפיגורציה שלהן, ואז מספיק ששם המשתמש במחשב שלך שונה משם משתמש של האדם האחרון שעשה commit, ואתה מקבל errors בפתיחת פרויקט.
 
רוב סביבות פיתוח שעבדתי איתן יודעות לייבא פרויקטים ישירות מסוגים רבים של source control, כך שאין צורך בעבודה מיוחדת כדי להשלים קבצי קונפיגורציה.
הסביבה תעשה checkout ותשלים בעצמה את הקבצים לפי קונפיגורציה מקומית שלך.
אומנם אלה הם ספציפית ל-git, אבל אפשר ללמוד מהם, ולהמיר אותם לכל SC:
https://github.com/github/gitignore
 
בגדול, חשוב להימנע מהכללת תוצרים בינאריים. זה ינפח את המאגר לשווא וגם יראה שינויים היכן שאין באמת כאלה (לא שינית כלום בקוד, אבל ה-time stamp של ה-build השתנה).
 
לגבי קבצי סביבת פיתוח - אם אתה ורק אתה עובד על הפרויקט ממחשב בודד, אז ניחה.
ברגע שיש עוד אנשים, זו צרה צרורה.
לרוב, סביבות פיתוח מכניסות נתיב אובסולוטי לחלק מקבצי הקונפיגורציה שלהן, ואז מספיק ששם המשתמש במחשב שלך שונה משם משתמש של האדם האחרון שעשה commit, ואתה מקבל errors בפתיחת פרויקט.
 
רוב סביבות פיתוח שעבדתי איתן יודעות לייבא פרויקטים ישירות מסוגים רבים של source control, כך שאין צורך בעבודה מיוחדת כדי להשלים קבצי קונפיגורציה.
הסביבה תעשה checkout ותשלים בעצמה את הקבצים לפי קונפיגורציה מקומית שלך.
לא יודע על מה אתה מדבר - איזה launcher?
כמו שכבר כתבתי, אני לא עוסק בפיתוח צד שרת, אבל כן עובד ועבדתי הרבה עם Eclipse ועם IntelliJ בבגדים של Android Studio.
 
האחרון, בכלל לא שואל איך לרשום את הנתיבים בקבצי קונפיגורציה שלו. אולי יש לזה הגדרה אי שם בנבחי מסכי ההגדרות, אבל זה לא משנה.
גם נתיב יחסי עלול לדפוק אותך, כשאתה עובר ממחשב למחשב.
 
וכאמור, לשתי הסביבות לא צריך ליצור כלום ידנית אם אומרים לסביבה עצמה לייבא פרויקט מ-CVS.
 
אגב, המצב שאתה מתאר נכון רק אם אתה כל הזמן מוחק את תיקיית העבודה שלך.
למה שתגיע למצב כזה?
אתה מחליף מחשבים כל הזמן?
אין לך מספיק מקום על הכונן הקשיח?
 
מעבר בין branch אחד לאחר לא אמור למחוק לך קבצים שאינם ב-CSV.
עם איזה CSV אתם עובדים, אם מותר לשאול?
כמו שכבר כתבתי, אני לא עוסק בפיתוח צד שרת, אבל כן עובד ועבדתי הרבה עם Eclipse ועם IntelliJ בבגדים של Android Studio.
 
האחרון, בכלל לא שואל איך לרשום את הנתיבים בקבצי קונפיגורציה שלו. אולי יש לזה הגדרה אי שם בנבחי מסכי ההגדרות, אבל זה לא משנה.
גם נתיב יחסי עלול לדפוק אותך, כשאתה עובר ממחשב למחשב.
 
וכאמור, לשתי הסביבות לא צריך ליצור כלום ידנית אם אומרים לסביבה עצמה לייבא פרויקט מ-CVS.
 
אגב, המצב שאתה מתאר נכון רק אם אתה כל הזמן מוחק את תיקיית העבודה שלך.
למה שתגיע למצב כזה?
אתה מחליף מחשבים כל הזמן?
אין לך מספיק מקום על הכונן הקשיח?
 
מעבר בין branch אחד לאחר לא אמור למחוק לך קבצים שאינם ב-CSV.
עם איזה CSV אתם עובדים, אם מותר לשאול?
חשבתי על זה רגע אחרי אחרי שסיימתי את ההדועה
אבל לא היה לי כוח לערוך.
 
נשמע לי קצת גן חיות, הרבה ספריות פרויקט לפי גרסאות.
מצד שני, המון זמן לא עבדתי עם svn.
 
אצלנו עובדים עם GIT. כשאתה עובר branch שום דבר לא זז לשום מקום, רק הקבצים בספריית העובדה משתנים.
 
תמיד אפשר לעשות עוד clone לספרייה נפרדת, אבל אין בזה צורך כי יש עותק repository מקומי אז לעשות checkout ל-branch לוקח קרוב ל-0 זמן.
 
אני מניח שאם עובדים ישירות מול repository מרכזי על שרת לוקח זמן לעשות checkout אז מעדיפים להחזיק branchים שונים מקומית בספריות שונות...
 
ואם אני זוכר נכון, כל עניין ה-branch ב-svn קצת מנוון ביחס לדברים יותר מודרניים כמו git.
אבל לא היה לי כוח לערוך.
 
נשמע לי קצת גן חיות, הרבה ספריות פרויקט לפי גרסאות.
מצד שני, המון זמן לא עבדתי עם svn.
 
אצלנו עובדים עם GIT. כשאתה עובר branch שום דבר לא זז לשום מקום, רק הקבצים בספריית העובדה משתנים.
 
תמיד אפשר לעשות עוד clone לספרייה נפרדת, אבל אין בזה צורך כי יש עותק repository מקומי אז לעשות checkout ל-branch לוקח קרוב ל-0 זמן.
 
אני מניח שאם עובדים ישירות מול repository מרכזי על שרת לוקח זמן לעשות checkout אז מעדיפים להחזיק branchים שונים מקומית בספריות שונות...
 
ואם אני זוכר נכון, כל עניין ה-branch ב-svn קצת מנוון ביחס לדברים יותר מודרניים כמו git.
לדעתי רצוי לכלול גם קבצים בינריים וקבצי קונפיגורציה
קבצי קונפיגורציה בד"כ לא גדולים ורצוי מאד שכל המתכנתים יעבוד באותה סביבת עבודה עם אותם קומפילרים ואותם ספריות, אחרת עלולים להווצר בעיות תאימות.
ולצמצם כמה שאפשר את קבצי הקונפיגורציה שאינם זהים אצל כל מתכנת ואותם לא לכלול.
לגבי קבצים בינריים רצוי לכלול את קובץ התוצר הסופי של הקומפילציה,בתנאי שהוא לא משתנה ( למעט אולי חתימת תאריך ) מקומפילציה חוזרת , ובתנאי שהוא לא גדול מידי (כמו למשל קבצי firmware למעבדים יעודיים מיקרו בקרים DSP וכו ).
זה מאד מאד עוזר שעושים שינויים שאינם אמורים להשפיע על הקוד כמו שינוי הערות ,שינוי מקרואים שינוי שמות משתנים וכו .... ואז מקמפלים ומשווים את קובץ התוצר עם זה הנמצא ב source control ואם הקבצים זהים סימן שלא שינינו את הקוד בטעות.
קבצי קונפיגורציה בד"כ לא גדולים ורצוי מאד שכל המתכנתים יעבוד באותה סביבת עבודה עם אותם קומפילרים ואותם ספריות, אחרת עלולים להווצר בעיות תאימות.
ולצמצם כמה שאפשר את קבצי הקונפיגורציה שאינם זהים אצל כל מתכנת ואותם לא לכלול.
לגבי קבצים בינריים רצוי לכלול את קובץ התוצר הסופי של הקומפילציה,בתנאי שהוא לא משתנה ( למעט אולי חתימת תאריך ) מקומפילציה חוזרת , ובתנאי שהוא לא גדול מידי (כמו למשל קבצי firmware למעבדים יעודיים מיקרו בקרים DSP וכו ).
זה מאד מאד עוזר שעושים שינויים שאינם אמורים להשפיע על הקוד כמו שינוי הערות ,שינוי מקרואים שינוי שמות משתנים וכו .... ואז מקמפלים ומשווים את קובץ התוצר עם זה הנמצא ב source control ואם הקבצים זהים סימן שלא שינינו את הקוד בטעות.
נראה לי שיטה קצת בזבזנית. חשבת על Unit Tests?
להכניס תוצר בינארי לSC צריך רק אם אתה צריך לוודא שיש לך העתק מדוייק של התוצר. למשל, אם אתה שולח חבילה ללקוח ואתה רוצה לוודא שכשאתה מדבג בעיה אתה עובד עם אותו הקוד בדיוק, והtoolchain עצמו לא בsc (אצלי למשל הtoolchain שמור בgit, כך שבהנתן תג אני יכול לשחזר בדיוק את אותו הקובץ הבינארי גם חמש שנים אחרי).
להכניס תוצר בינארי לSC צריך רק אם אתה צריך לוודא שיש לך העתק מדוייק של התוצר. למשל, אם אתה שולח חבילה ללקוח ואתה רוצה לוודא שכשאתה מדבג בעיה אתה עובד עם אותו הקוד בדיוק, והtoolchain עצמו לא בsc (אצלי למשל הtoolchain שמור בgit, כך שבהנתן תג אני יכול לשחזר בדיוק את אותו הקובץ הבינארי גם חמש שנים אחרי).
אכן אני צריך מידי פעם לוודא שיש לי העתק מדויק של המוצר
אחרי שבצעתי בו שינויים שלא אמורים לשנות את הקוד הבינרי.
זה עוזר לי גם אם אני מתעדכן בקבצי מקור שתכנת אחר עשה בו שינויים ,וקימפל ובדק ב unit test שלו. אז אני מקמפל אצלי ומוודא שיצא לי אותו קוד בינרי כמו שיצא לו, ואם זה לא זהה אז כנראה לא התעדכני עם קבצי המקור הנכונים או לא עם כולם או שהוא שכח להעביר לsource control חלק מקבצי המקור וכולי.
 
 
אחרי שבצעתי בו שינויים שלא אמורים לשנות את הקוד הבינרי.
זה עוזר לי גם אם אני מתעדכן בקבצי מקור שתכנת אחר עשה בו שינויים ,וקימפל ובדק ב unit test שלו. אז אני מקמפל אצלי ומוודא שיצא לי אותו קוד בינרי כמו שיצא לו, ואם זה לא זהה אז כנראה לא התעדכני עם קבצי המקור הנכונים או לא עם כולם או שהוא שכח להעביר לsource control חלק מקבצי המקור וכולי.
 
 
Copyright©1996-2021,Tapuz Media Ltd. Forum software by XenForo® © 2010-2020 XenForo Ltd.