อาร์กิวเมนต์จะทำการตรวจสอบไฟล์ไบนารีอีกครั้งใน SCM


10

ฉันทำงานให้กับ บริษัท ที่สร้างแอปพลิเคชัน Java เป็นหลักและฉันพยายามโน้มน้าวให้ทุกคนหยุดตรวจสอบไฟล์ไบนารี่ (การอ้างอิงและผลิตภัณฑ์ขั้นสุดท้าย) ไปยัง SCM

พวกเขารู้ว่ามันเป็นวิธีปฏิบัติที่ไม่ดี แต่พวกเขาคิดว่า "มันใช้งานได้" และมันก็ไม่ได้เป็นปัญหาจริงๆแม้ในขณะที่หลายคนรู้เกี่ยวกับ Maven และเครื่องมืออื่น ๆ สำหรับการสร้างนอกเหนือจาก Ant ทั้งนักเขียนบทละครและโปรแกรมเมอร์ (ประมาณ 50 คน) พร้อมที่จะรับฟังข้อโต้แย้งใด ๆ และยอมรับว่ามันเสียพื้นที่ในการสำรองข้อมูล แต่ฉันต้องการที่จะเชื่ออย่างแท้จริงเพราะการเปลี่ยนนิสัยจะต้องใช้ความพยายามอย่างมาก คุณใช้ข้อโต้แย้งอะไรเพื่อสนับสนุนการเปลี่ยนแปลง

แก้ไข:โอเคมันสมเหตุสมผลแล้วที่จะแยกความแตกต่างระหว่างไฟล์ที่แทบจะไม่เปลี่ยนแปลงเช่นการพึ่งพาและการสร้างไฟล์ ถึงอย่างนั้นฉันก็ให้ความสนใจในเหตุผลต่อหลัง

คำตอบ:


7

พื้นที่เก็บข้อมูลราคาถูกและนั่นไม่ใช่เหตุผลที่น่าเชื่อถือมากสำหรับเหตุผลที่คุณควรหรือไม่ควรตรวจสอบไฟล์

คุณสามารถอุทธรณ์ถึงวัตถุประสงค์ของ SCM ได้ แต่ละไฟล์ที่ถูกติดตามโดย SCM แสดงถึงความต้องการในการจัดการการเปลี่ยนแปลงแบบขนานที่ทีมของคุณกำลังทำ ไม่มีสิ่งใดที่ชัดเจนจริงๆจนกระทั่งสมาชิกในทีมสองคนพยายามเปลี่ยนไฟล์เดียวกัน การแก้ไขการเปลี่ยนแปลงเหล่านั้นคือสิ่งที่ SCM มีไว้เพื่อป้องกันการเขียนทับงาน dev อื่นโดยไม่ตั้งใจและหวังว่าจะทำให้กระบวนการรวมการเปลี่ยนแปลงเหล่านั้นเป็นไปโดยอัตโนมัติ

การรวมไฟล์ไบนารีมักเป็นความท้าทายที่แท้จริงเพราะไม่มีวิธีที่ดีที่เครื่องมือผสานทั่วไปจะเดาได้ว่าไฟล์ไบนารีที่ผสานควรทำงานอย่างไร ไม่สามารถรู้ได้อย่างเพียงพอเกี่ยวกับวิธีการที่ดัชนีหรือออฟเซ็ตพอยน์เตอร์ในการทำงานของไฟล์ยกเว้นว่าได้รับการออกแบบมาเป็นพิเศษเพื่อให้จดจำประเภทไฟล์นั้น ๆ

นั่นหมายความว่ามันขึ้นอยู่กับผู้พัฒนาที่จะรวมไฟล์ไบนารีด้วยมือแล้วบอก SCM ว่าไฟล์ถูกรวมเข้าด้วยกัน เนื่องจากเป็นการพัฒนาที่ทำได้การผสานอาจไม่ครอบคลุมการเปลี่ยนแปลงทั้งหมดของการเช็คอินก่อนหน้านี้ทั้งหมดและเนื่องจากไฟล์เป็นแบบไบนารีจึงไม่มีวิธีอัตโนมัติในการตรวจสอบการรวม

สำหรับรูปแบบไบนารี่ที่แสดงถึงแหล่งที่มาของโครงการเช่นสินทรัพย์ศิลปะนี่เป็นขั้นตอนที่โชคร้าย แต่เป็นสิ่งจำเป็น อย่างไรก็ตามการสร้างผลลัพธ์ไม่ใช่แหล่งที่มา ไม่จำเป็นต้องรวมพวกเขาเพราะแหล่งที่มาสามารถผสานและสร้างผลการสร้างสามารถสร้างขึ้นมาใหม่ การติดตามและจัดการการเปลี่ยนแปลงเหล่านี้เป็นของเสีย 100% มันเป็นการสูญเสียทรัพยากรของ SCM แม้ว่าจะไม่มากนัก แต่มันก็เป็นการเสียเวลาของนักพัฒนาที่จะผ่านความล้มเหลวที่เกิดจากการรวมเข้าด้วยกัน เวลานักพัฒนามีราคาแพงมากและสิ่งที่ทำให้เสียคือมะเร็ง

ในอีกทางหนึ่งมีกรณีเฉพาะที่สร้างผลลัพธ์ที่ควรเก็บถาวร โครงการเวอร์ชันใด ๆ ที่เคยมีการจัดส่งหรือนำไปใช้งานควรจะคงไว้ตลอดไป การมีไบต์ที่แน่นอนสำหรับสำเนาแบบไบต์ของการสร้างจริงที่ลูกค้ากำลังประสบกับสามารถทำให้การสนับสนุนลูกค้านั้นง่ายขึ้นมากเนื่องจากคุณจะมีรุ่นที่แน่นอนที่เขามี

การสำรองข้อมูลนั้นอาจไม่ควรอยู่ในที่เก็บเดียวกันกับซอร์สโค้ดเนื่องจากโดยทั่วไปแล้วจะเป็นไปตามกำหนดเวลาที่แตกต่างกันและมีโครงสร้างที่แตกต่างกันโดยทั่วไป


10

ควรมีการตรวจสอบการพึ่งพาแม้ในรูปแบบไบนารีดังนั้นเมื่อมีคนดึงโครงการลง ข้อกังวลหลักไม่ใช่ประเภทของไฟล์ แต่เป็นวิธีสร้างไฟล์ กฎง่ายๆที่ฉันใช้คือถ้ามันสามารถสร้างขึ้นโดยใช้ไฟล์อื่นมันจะไม่ได้รับการตรวจสอบซึ่งหมายถึงเอกสารที่สร้างขึ้นโดยอัตโนมัติไฟล์ไบนารีที่ฉันสร้างและอื่น ๆ


2

หนึ่งในข้อได้เปรียบหลักของการใช้ SCM คือคุณสามารถสร้างระบบของคุณใหม่ได้ตลอดเวลาในอดีต ดังนั้นจึงไม่มีประเด็นใดที่จะจัดเก็บงานสร้างสุดท้ายของคุณใน SCM ของคุณเพราะคุณสามารถตรวจสอบหมายเลขการแก้ไขและสร้างได้

คุณพูดถึงการพึ่งพา ... SCM ของคุณควรจะตั้งค่าเพื่อให้คุณสามารถชำระเงินที่สะอาดกับเครื่องใหม่ (ด้วยสภาพแวดล้อม dev), hit build และคุณควรจะสามารถสร้างระบบของคุณโดยไม่จำเป็นต้องติดตั้งอะไรอีก ดังนั้นการรักษาความไว้วางใจแบบไบนารีใน SCM ของคุณจึงเป็นความคิดที่ดี ห้องสมุดไม่ค่อยมีการเปลี่ยนแปลงดังนั้นพวกเขาจะไม่ใช้พื้นที่มาก

แทบไม่มีใครทำสิ่งนี้


ตกลงฉันเห็นด้วย: การพึ่งพาไม่ค่อยเปลี่ยนแปลง แต่ไฟล์ WAR ขนาด 20Mb ที่มีซอร์สโค้ดหนึ่งบรรทัดเปลี่ยนไปไม่ควรทำการเช็คอิน
ither

3
ทำไมจะไม่ล่ะ? คุณจะใช้พื้นที่ดิสก์หมดหรือไม่ หากคุณไม่มีแหล่งที่มาและเป็นสิ่งที่ต้องพึ่งพาคุณก็ไม่มีทางเลือกถ้าคุณทำเช่นนั้นมันจะไม่นับเป็นไบนารีและคุณสามารถสร้างมันได้เมื่อคุณต้องการ
เฮนรี่

0

ดูเหมือนว่าซ้ำซ้อนเพื่อรวมทั้งซอร์สและไฟล์ออบเจ็กต์ (จำเป็นต้องมีซอร์สไฟล์) นอกเหนือจากการไม่จำเป็นเพียงแค่ไฟล์วัตถุสามารถกินพื้นที่มาก หาก บริษัท ของคุณกำลังใช้ SCM แบบกระจาย (Git, Hg, Bzr) ดังนั้นไฟล์ไบนารีเหล่านั้นจะต้องถูกคัดลอกและจัดเก็บในบรรดานักพัฒนาทั้งหมด

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.