การเปิดตัวล่าสุดของ Evo ระบบควบคุมเวอร์ชันใหม่ที่สัญญาว่าจะทำให้การจัดการโค้ดง่ายขึ้น ได้จุดประเด็นการถกเถียงอย่างมากในหมู่นักพัฒนาที่ตั้งคำถามว่าแนวทางการทำงานบนเวิร์กสเปซจะสามารถแก้ปัญหาการพัฒนาในโลกความเป็นจริงได้จริงหรือไม่
ข้อกังวลในทางปฏิบัติเกี่ยวกับโมเดลเวิร์กสเปซ
ในขณะที่ Evo นำเสนอขั้นตอนการทำงานบนเวิร์กสเปซที่เรียบง่ายสำหรับแต่ละฟีเจอร์ เพื่อเป็นทางเลือกแทนระบบการแตกกิ่ง (branching) ของ Git นักพัฒนาที่มีประสบการณ์กำลังแสดงความกังวลเกี่ยวกับความเป็นไปได้ในทางปฏิบัติ การทำงานแบบเชิงเส้นที่นำเสนอ ซึ่งนักพัฒนาสร้างเวิร์กสเปซสำหรับแต่ละฟีเจอร์ ทำงานให้เสร็จ และรวมเข้าด้วยกัน ดูเหมือนจะทำให้ธรรมชาติที่ซับซ้อนของการพัฒนาซอฟต์แวร์ดูง่ายเกินไป นักพัฒนาหลายคนชี้ให้เห็นว่าการพัฒนาในโลกความเป็นจริงแทบจะไม่เคยเป็นไปตามเส้นทางที่ตรงไปตรงมาเช่นนี้ โดยงานมักเกี่ยวข้องกับการเปลี่ยนแปลงที่เชื่อมโยงกันหลายส่วนและการพัฒนาที่ขนานกันไป
ผมรู้สึกสงสัยกับอะไรก็ตามที่สันนิษฐานว่าต้องใช้หนึ่งกิ่งหรือเวิร์กสเปซต่อหนึ่งฟีเจอร์ ตลอดอาชีพของผมไม่เคยทำงานแบบนั้นเลย ผมต้องจัดการกับการเปลี่ยนแปลงหลายๆ อย่างที่จะถูกรีวิวและรวมเข้าด้วยกันในเวลาใกล้เคียงกันแต่แยกกัน
ข้อกังวลของชุมชน:
- ข้อจำกัดของขั้นตอนการทำงานแบบเชิงเส้น
- ความชัดเจนของคำสั่งและเอกสารประกอบ
- การจัดการสถานการณ์การรวมที่ซับซ้อน
- การแยกฟีเจอร์กับการพัฒนาแบบขนาน
- ความเข้ากันได้กับการทำงานในสถานการณ์จริง
บริบททางประวัติศาสตร์และความท้าทายทางเทคนิค
การอภิปรายได้นำมาซึ่งการเปรียบเทียบที่น่าสนใจกับระบบควบคุมเวอร์ชันก่อนหน้านี้ โดยเฉพาะ Darcs ซึ่งใช้แนวทางการจัดการแพตช์แทนที่จะเน้นที่ประวัติการแก้ไข การถกเถียงในชุมชนชี้ให้เห็นถึงความตึงเครียดพื้นฐานในการออกแบบระบบควบคุมเวอร์ชัน: ควรให้ความสำคัญกับการจัดการแพตช์ (ฟีเจอร์) หรือการแก้ไข นักพัฒนาบางคนสังเกตว่าทางออกที่ดีที่สุดอาจจำเป็นต้องรวมทั้งสองแนวคิดเข้าด้วยกันอย่างมีประสิทธิภาพ
ข้อกังวลเกี่ยวกับเอกสารทางเทคนิคและความชัดเจน
นักพัฒนายังได้หยิบยกประเด็นเกี่ยวกับความชัดเจนของคำสั่งและเอกสารของ Evo คำสั่ง evo workspace merge ถูกวิจารณ์ว่ามีความคลุมเครือเมื่อเทียบกับคำสั่ง Git ที่ตรงไปตรงมากว่า เช่น push สิ่งนี้ชี้ให้เห็นถึงความกังวลที่กว้างขึ้นว่าการทำให้การควบคุมเวอร์ชันง่ายขึ้นจะนำไปสู่การใช้งานที่ดีขึ้นจริงหรือไม่ โดยเฉพาะเมื่อแนวคิดพื้นฐานยังคงซับซ้อน
คุณสมบัติหลักของ Evo:
- รูปแบบการพัฒนาที่อิงตามพื้นที่ทำงาน
- รองรับไฟล์ขนาดใหญ่แบบในตัว
- การผสานโครงสร้างสำหรับไฟล์ JSON และ YAML
- สถาปัตยกรรมที่ทำงานแบบออฟไลน์เป็นหลัก
- การเซ็นยืนยันการคอมมิตด้วย Ed25519
- การสื่อสารระหว่างไคลเอนต์และเซิร์ฟเวอร์ด้วย HTTP/2
การตรวจสอบคุณสมบัติสำหรับองค์กร
ในขณะที่ Evo โอ้อวดการรองรับไฟล์ขนาดใหญ่และการรวมเชิงโครงสร้างสำหรับไฟล์การกำหนดค่า ชุมชนกำลังร้องขอข้อมูลที่ละเอียดมากขึ้นเกี่ยวกับวิธีการทำงานจริงของคุณสมบัติเหล่านี้ โดยเฉพาะอย่างยิ่ง นักพัฒนาสนใจที่จะเห็นการสาธิตวิธีที่ระบบจัดการกับการรวมหลายฟีเจอร์ที่มีความขัดแย้ง และวิธีจัดการกับไฟล์ประเภทต่างๆ ตั้งแต่โค้ดที่เป็นข้อความไปจนถึงไฟล์สื่อขนาดใหญ่
ความสงสัยจากชุมชนนักพัฒนาชี้ให้เห็นว่าแม้จะมีความสนใจจริงในการปรับปรุงเครื่องมือควบคุมเวอร์ชัน แต่โซลูชันใหม่ใดๆ จำเป็นต้องจัดการกับความซับซ้อนที่เป็นจริงของการพัฒนาซอฟต์แวร์สมัยใหม่อย่างละเอียดถี่ถ้วน แทนที่จะเพียงแค่ทำให้อินเตอร์เฟซง่ายขึ้น