เหตุใดที่เก็บ Git / Mercurial จึงใช้พื้นที่น้อย

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

— Alex Florescu
แหล่งที่มา

followinfg โพสต์ที่คุณอ่านหรือไม่? stackoverflow.com/questions/7727791/…หรือstackoverflow.com/questions/8657710/…หรือstackoverflow.com/questions/456336/…

— VonC

ฉันยังไม่ได้ขอบคุณ! ดังนั้นฉันเข้าใจจากผู้ที่มีสองคำตอบ: การบีบอัดโดยใช้ zlib และบันทึกวัตถุเป็น packfiles เมื่อเป็นไปได้ ตัวอย่างจาก Mozilla ก็ยอดเยี่ยมเช่นกัน!

— Alex Florescu

@ อเล็กซ์ไม่ใช่เพราะคิดถึงเหตุผลหลัก SVN บันทึกสแน็ปช็อตที่สมบูรณ์ Git และ Mercurial บันทึกเฉพาะการแก้ไข HEAD และความแตกต่าง การใช้การบีบอัดแบบธรรมดาสามารถให้อัตราการบีบอัดที่ดีที่สุดประมาณ 60–80% การใช้ diffs สามารถให้คุณได้มากถึง 99% ตัวเลขเหล่านี้ถูกดึงออกมาจากก้นของฉัน - ตัวเลขจริงอาจแตกต่างกัน แนวโน้มที่จะเป็น แต่เดียวกัน

— Konrad Rudolph

@ KonradRudolph ไม่ว่าแพ็คไฟล์จะเกี่ยวกับอะไร

— Alex Florescu

@Alex ไม่ได้จริงๆ เท่าที่ฉันรู้ packfile ยังบรรจุไฟล์หลายไฟล์เป็นหนึ่ง สิ่งนี้ไม่จำเป็นต้องเกี่ยวข้องกัน

— Konrad Rudolph

จากประสบการณ์ของฉันข้อความต่อไปนี้ล้วนเป็นความจริง:

Git นั้นมีประสิทธิภาพมากในการจัดเก็บไฟล์ข้อความและเฉพาะการจัดเก็บไฟล์เหล่านี้ที่มีการเปลี่ยนแปลง ดังนั้นเมื่อทำการเปรียบเทียบ SVN และ Git เพื่อเปรียบเทียบขนาดพื้นที่เก็บข้อมูลพวกเขาอาจคล้ายกันหรืออาจมีข้อได้เปรียบเล็กน้อยสำหรับ Git
นี่เป็นความผิดอย่างสมบูรณ์ถ้าคุณเปรียบเทียบขนาดของที่เก็บซึ่งจำนวนไฟล์ที่สำคัญคือไฟล์ office (เช่น MS word, excel, powerpoint, ... ) ที่นี่ Git เก็บสำเนาที่สมบูรณ์ด้วยซึ่งหมายความว่าการเปลี่ยนแปลงเพียงเล็กน้อย 10 รายการใน powerpoint slide stack จะส่งผลให้มี 10 สำเนาที่สมบูรณ์โดย Subversion เก็บเฉพาะไบนารี diff ซึ่งอาจเป็นปัจจัยที่เล็กกว่า 100 รายการ

หากคุณเปรียบเทียบตำแหน่งเช็คเอาต์ (ซึ่งเป็นที่เก็บในตัวเองกับ Git) เรื่องราวนั้นแตกต่างกันโดยสิ้นเชิง:

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

หากคุณเปรียบเทียบจำนวนไบต์ที่คุณต้องดาวน์หรืออัปโหลดมันจะแตกต่างกันอีกครั้ง

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

ดังนั้นในตอนท้ายคุณเปรียบเทียบแอปเปิ้ลกับส้มและขึ้นอยู่กับสิ่งที่คุณต้องการจะทำกับ Subversion หรือ Git ผลลัพธ์อาจแตกต่างกัน

@jk ถามถึงสำเนาที่สมบูรณ์หรือความแตกต่างแบบไบนารีและฉันไม่สามารถตอบคำถามนั้นได้ ฉันถามแมทธิวแมคคัลล็อกซึ่งให้การประชุมเชิงปฏิบัติการเรื่อง Git เมื่อเร็ว ๆ นี้ที่ Jax 2012 (ซึ่งฉันไปเยี่ยม) เขาใช้เวลา (ขอบคุณมากกับเขา) เพื่ออธิบายรายละเอียดเกี่ยวกับการทำงานภายในของ Git ใช่แล้วมีการบีบอัดที่ทำงานอยู่ที่นั่น (และฉันจะทำการทดสอบกับไฟล์ Microsoft Office เช่นกันและจะเปรียบเทียบกับส่วนสำคัญของเขา) แต่ไม่มีการบีบอัดจะทำกับไฟล์ทั้งหมด อ้างจากส่วนสำคัญของเขา:

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

— mliebelt
แหล่งที่มา

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

— jk

ถามใครบางคน (ทางอีเมล) ซึ่งรู้มากกว่าฉันและจะรวมคำตอบของเขาในคำตอบของฉันแล้ว

— mliebelt

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

— Jan Hudec

วัตถุที่หลวมและเต็มไปไม่มีส่วนเกี่ยวข้องกับข้อความและไบนารี มันเป็นค่าตัดจำหน่ายของงานที่ยากในการหาเลขฐานสอง ความเร็วเป็นคุณสมบัติที่สำคัญของคอมไพล์ดังนั้นระหว่างการทำงานปกติคอมไพล์เพียงบีบอัดข้อมูลใหม่และตบมันในที่เก็บ นี่คือวัตถุที่หลวม กว่าเมื่อคุณถามโดยการเรียกgit gcหรือรวบรวมวัตถุหลวมมากเกินไปพบว่าผู้สมัครที่ดีที่จะบีบอัดเดลต้ากับพวกเขา (คอมไพล์สามารถแตกต่างจากรุ่นก่อนหน้า) เก็บเดลตาใน "แพ็ค" และลบวัตถุหลวม

— Jan Hudec

สำหรับผู้ที่สนใจตัวเลขในโลกแห่งความจริง: ฉันเพิ่งเปรียบเทียบสำเนาการทำงานสองฉบับจาก repo เดียวกัน สำเนาทำงาน SVN มีขนาดประมาณ 2,9 GB สำเนาทำงานของGITอยู่ที่ประมาณ 0,8 GB

— JensG