יש לכם blacklist של דברים שלא נכנסים לsource control?

[הפרבולה]

אם הקובץ הבינרי של A זהה לקודם אז מיותר לגמרי להריץ שוב

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

 

[ipv6]

אתה מפספס את הרעיון

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

בינארי שהועבר ל-Production
אם חשוב לך שבינארי כלשהוא לא ישתנה נניח מטעמי חתימות\אבטחה אתה יכול למצוא פונקציית hash שנותן לך את מה שאתה רוצה.

 

[הפרבולה]

אם אני מבין נכון אז הרעיון של ה HASH זה רק לחסוך מקום

ב source control ,בסדר, אפשר לעשות להם ZIP למשל ( אני לא חושב שיש HASH שיתן חתימה קטנה יותר ועדין ישמור על חד חד ערכיות, אלה אם יש שיטת כיווץ יעילה יותר מה ZIP או ה RAR הידוע )
בכל אופו קבצי firmware אצלינו לא כאלו גדולים ( בסדר גודל של קבצי המקור עצמם )

 

[BravoMan]

אתה באמת צריך לקרוא על פונקציות hash, זה ידע הכרחי:

https://en.wikipedia.org/wiki/Hash_function
&nbsp
יש להן דיוק חד-חד ערכי טוב מספיק לצורכי הצפנה, אבטחת מידע, והדנה מפני ווירוסים.
&nbsp
הן בהחלט טובות מספיק לצורך שלך.
&nbsp
אגב, שכחתי להגיד זאת, אבל עבור הרבה מפתחים, התוצר הבינארי גם של אפליקציה פשוטה ביותר יהיה בגודל של 1MB ומעלה, כך שכנראה רוב האנשים פה כותבים מתוך שיקולי גודל שונים לחלוטין, וזה בוודאות כולל אותי.

 

[BravoMan]

אני לא בטוח מה אתה מכנה "אפליקציה" ומה המגבלות

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

 

[הפרבולה]

מדובר בקובץ קוד משותף ל 2 או יותר אפליקציות דומות

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

בשלב מסוים חלק מהאפליקציות מוקפאות ( נשלחו ללקוח ) ואסור לעשות בהם שינויים , אבל באפליקציות שעדין לא הוקפאו לפעמים יש צורך להוסיף שינוים ספציפיים ואז מכניסים אותם תחת #ifdef ונוצר צורך לבדוק שהאפליקציות המוקפאות לא השתנו. .
במידה והחלקים השונים מתרבים יותר מידי אכן יש לשקול לפצל לקבצים נפרדים לכל אפליקציה ומוחקים את ה #ifdef ( וגם אז מוודאים בהשוואה בינרית שהאפיקkציות המוקפאות לא השתנו ).

 

[BravoMan]

לא שמעו אצלכם על branch ב-source control?

אתם מפצלים את הקוד דרך הוראות פריפרוססור במקום להקפיא גרסה דרך מערכת source control שזה אחד היעודים שלה?
&nbsp
למה?
&nbsp
אני מתנצל אם הכותרת נשמעת קצת מעליבה, פשוט הופתעתי מהשיטה הזו כי מעולם לא שמעתי על מישהו שפועל כך.
&nbsp
אני מכיר מי שלא משתמש ב-source control בכלל ואז פשוט יוצר עותק מלא של הפרויקט כדי להקפיא גרסה, ומכיר מי שמשתמש ב-source control ועושה branch.
&nbsp
יש לכם בהחלט שיטת עבודה מקורית, לפחות מבחינתי!

 

[הפרבולה]

הנה עוד דוגמה לפיצול קוד

שלא קשור להקפאת גרסאות.
2 אפליציות A ו B מממשות את אותו אלגוריתם שתוצאתו הסופית אמורה להרשם לרגיסטר חומרה, אבל באחד יש לרשום את התוצאה לרגיסטר 16 ביט ובשני יש לרשום את התוצאה לרגיסטר 32 ביט ( שמיוצג על ידי 2 רגיסטרי חומרה 16 ביט ). וזה בגלל שהחומרה של 2 המוצרים שונה ( וגם המחיר שלהם)
אז הקוד המשותף יראה ככה:


//same algorithm that it's output written is 32 bit integer value to "result"
...................
#ifdef RESULT_16BIT
if( result>=32768) result=32767;
if( result<=-32768) result=-32767;
reg = result;
#else
regLSB=result;
regMSB =result>>16;
#end

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

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

 

[BravoMan]

זה שימוש מקובל ומוכר לפיצול קוד

שנתקלתי בו לא פעם ב-kernel ואפילו בסביבת userspace של Android.
&nbsp
אבל אני מתקשה להבין איך השוואת בינארים במקרה זה פותרת את הבעיה?
נניח שמשנים חלק שרלוונטי למכונה 16 ביט, מה עושים אז?
&nbsp
מקמפלים את הקוד של אחת האפליקציות לגרסה 32 ביט ומחפשים בינארי של אותה אפליקציה באותה גרסה שקומפל מקוד ללא השינוי כדי להשוות אליו?
&nbsp
או שכל אפליקציה בעצם נועדה לרוץ רק על סוג מסוים של חומרה, ואז תיקון עבור 16 ביט למשל, ישפיע רק על בינארי של אפליקציה A?
&nbsp
בד"כ, כשיש פרויקט משותף לכמה חומרות עם פיצול מהסוג הזה בקוד, קביעת סוג החומרה מתבצעת ברמת מערכת ה-build, לא ברמת קבצי המקור, אז נניח שקימפלת בינארי ל-32 ביט, ואתה רוצה לוודא שהו זהה לגרסה מלפני השינויים.
&nbsp
פתאום אתה מוצא שהוא שונה.
איך אתה יודע בוודאות שהוא שונה בגלל שבטעות נכנס שינוי בחלק לא נכון של הקוד, ולא בגלל שבטעות הפעלת פלאג חומרה לא נכון בזמן הקומפילציה?

 

[הפרבולה]

השוואה בינארים מוודאת שלא שיניתי בטעות

את גרסת התוכנה שלא היתה אמורה להשתנות . אם עשיתי שינוי בקוד הפלט של גרסת ה 16 ביט אני מקמפל גם את גרסת ה 32 ביט ומשווה את התוצר הבינארי לתוצר הבינארי האחרון שלה שנמצא ב source control ואם זהה אז בסדר.

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

 

[ipv6]

בד"כ לא מכניסים בינאריים

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

שמעתי על חברות ששומרות מסמכים ב-Source Control.

 

[user32]

לגבי קבצים בינאריים

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

 

[vinney]

עדיין עושים את זה?

פעם פעם לפני שנים רבות היה בחברה שעבדתי sourcesafe מיוחד למסמכים...
&nbsp
אבל מאז שפיתחו change tracker בוורד, ועבר קצת זמן מאז, לא נתקלתי בזה... מקסימום שראיתי זה ששומרים דברים בsharepoint (שזה גם סוג של SC), או ויקי.

 

[zaske]

המטבע המתומן שלי (העליתי את התעריף ל50 סנט)

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

לגבי קבצי הפרוייקט - וואלה, תעשה
gradlew idea

וגמור עניין, יש לך קבצי פרוייקט.

הלאה - לקבצי קוניפוגרציה צור טמפלייט - למשל log4j.xml.example ושם שים קוד של טמפלייט עם הערה של xml מה בדיוק למלא כדי שגם תוכי יבין.

 

[Rשף]

כשעברנו ל GIT רוב הבינאריים נשארו בחוץ

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