มีเอกสาร "Git สำหรับผู้ใช้ Perforce" จำนวนมากอยู่ที่นั่น แต่ดูเหมือนจะตรงกันข้ามน้อยมาก

ก่อนหน้านี้ฉันเคยใช้ Git มาก่อนและเพิ่งเริ่มงานที่ฉันต้องใช้ Perforce บ่อยๆและพบว่าตัวเองสับสนมากตลอดเวลา แนวคิดที่ฉันคุ้นเคยจาก Git ดูเหมือนจะไม่แม็พกับ Perforce เลย

มีใครสนใจที่จะรวบรวมเคล็ดลับในการใช้ Perforce สำหรับคนที่คุ้นเคยกับ Git หรือไม่?

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

บทนำสู่ Perforce สำหรับผู้ใช้ Git

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

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

หากคุณไม่สามารถโน้มน้าวให้ผู้ดูแลระบบของคุณติดตั้ง Git Fusion ได้ Git นั้นมาพร้อมกับ Perforce binding ที่เรียกว่า Git-P4 ซึ่งอนุญาตให้คุณใช้ Git เพื่อเปลี่ยนและส่งไฟล์ในพื้นที่ทำงาน Perforce ข้อมูลเพิ่มเติมเกี่ยวกับสิ่งนั้นสามารถดูได้ที่: https://git.wiki.kernel.org/index.php/GitP4

ยังอยู่ที่นี่? ดีมาดูที่เพอร์ฟอร์ซ

ความแตกต่างของคำศัพท์เพื่อเรียงลำดับ

ก่อนที่เราจะลงรายละเอียดเราต้องสรุปความแตกต่างของคำศัพท์ระหว่าง Git และ Perforce อย่างย่อ

ประการแรกคือการเช็คเอาท์ ใน Git นี่คือวิธีที่คุณได้รับสำเนาของรหัสจากสาขาที่กำหนดไว้ในพื้นที่ทำงานของคุณ ใน Perforce เราเรียกสิ่งนี้ว่าการซิงค์จากบรรทัดคำสั่งหรือจาก GUI P4V ของเรา "รับการแก้ไขล่าสุด" Perforce ใช้การชำระเงินคำจาก P4V หรือp4 editจากบรรทัดคำสั่งเพื่อหมายความว่าคุณวางแผนที่จะเปลี่ยนไฟล์จากระบบควบคุมเวอร์ชัน ในส่วนที่เหลือของเอกสารนี้ฉันจะใช้การชำระเงินในความหมายของคำ

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

แนวคิดหลักในการบังคับอย่างง่าย

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

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

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

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

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

ทำไมพื้นที่ทำงาน

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

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

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

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับอำนาจเต็มของพื้นที่ทำงานอย่างเลี่ยงไม่พ้นอ่านการกำหนดค่า P4

การชำระเงินอย่างชัดแจ้งกับการชำระเงินโดยนัย

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

ข่าวดีก็คือถ้าคุณเลือกคุณสามารถทำงานกับเวิร์กโฟลว์สไตล์ Git ใน Perforce ใน Perforce คุณสามารถตั้งค่าตัวเลือก "allwrite" บนพื้นที่ทำงานของคุณ สิ่งนี้จะบอก Perforce ว่าควรเขียนไฟล์ทั้งหมดลงดิสก์ด้วยชุดบิตที่เขียนได้ จากนั้นคุณสามารถเปลี่ยนไฟล์ใด ๆ ที่คุณต้องการโดยไม่ต้องบอก Perforce อย่างชัดเจน ในการให้ Perforce ปรับการเปลี่ยนแปลงเหล่านั้นให้เรียบร้อยคุณสามารถเรียกใช้ "สถานะ p4" มันจะเปิดไฟล์สำหรับเพิ่มแก้ไขและลบตามความเหมาะสม เมื่อทำงานด้วยวิธีนี้คุณจะต้องใช้ "p4 update" แทนที่จะเป็น "p4 sync" เพื่อรับการแก้ไขใหม่จากเซิร์ฟเวอร์ "p4 update" ตรวจสอบการเปลี่ยนแปลงก่อนทำการซิงค์ดังนั้นจะไม่ปิดบังการเปลี่ยนแปลงในเครื่องของคุณหากคุณยังไม่ได้เรียกใช้ "สถานะ p4"

ทำไมต้องชำระเงินอย่างชัดเจน?

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

เหตุผลหนึ่งที่ใช้การชำระเงินอย่างชัดเจนคือไม่จำเป็นต้องสแกนไฟล์เพื่อการเปลี่ยนแปลงเนื้อหา ในขณะที่โครงการขนาดเล็กที่คำนวณค่าแฮชสำหรับแต่ละไฟล์เพื่อค้นหาความแตกต่างนั้นค่อนข้างถูก แต่ผู้ใช้ของเราหลายคนมีไฟล์นับล้านในพื้นที่ทำงานและ / หรือมีไฟล์ที่มีขนาด 100 เมกะไบต์หากไม่ใหญ่กว่า การคำนวณแฮชทั้งหมดในกรณีเหล่านี้ใช้เวลานานมาก การชำระเงินอย่างชัดเจนช่วยให้ Perforce ทราบว่าต้องใช้ไฟล์ใดในการทำงาน พฤติกรรมนี้เป็นหนึ่งในเหตุผลที่ Perforce ได้รับความนิยมในอุตสาหกรรมไฟล์ขนาดใหญ่เช่นอุตสาหกรรมเกมภาพยนตร์และฮาร์ดแวร์

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

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

หากคุณใช้ IDE สำหรับการพัฒนาเช่น Visual Studio หรือ Eclipse ฉันขอแนะนำให้ติดตั้งปลั๊กอิน Perforce สำหรับ IDE ของคุณ ปลั๊กอิน IDE ส่วนใหญ่จะทำการเช็กเอาต์ไฟล์โดยอัตโนมัติเมื่อคุณเริ่มแก้ไขโดยไม่ต้องทำการเช็คเอาต์ด้วยตัวเอง

บังคับแทนสำหรับคุณสมบัติ Git

• git stash ==> p4 shelve
• git local branching ==> Perforce racks หรือสาขางาน
• git blame==> p4 annotateหรือPerforce Timelapse Viewจาก GUI

การทำงานตัดการเชื่อมต่อ

มีสองตัวเลือกสำหรับการยกเลิกการเชื่อมต่อการทำงานจากบริการกำหนดเวอร์ชันของ Perforce (นั่นคือคำศัพท์ที่ยอดเยี่ยมของเราสำหรับเซิร์ฟเวอร์ Perforce)

1) ใช้ P4Sandbox เพื่อให้มีเวอร์ชั่นในท้องถิ่นและการแตกสาขา

2) แก้ไขไฟล์ตามที่คุณต้องการและใช้ 'สถานะ p4' เพื่อบอกถึงสิ่งที่คุณได้ทำ

ด้วยตัวเลือกทั้งสองข้างต้นคุณสามารถเลือกใช้การตั้งค่า "allwrite" ในพื้นที่ทำงานของคุณเพื่อที่คุณจะได้ไม่ต้องปลดล็อคไฟล์ เมื่อทำงานในโหมดนี้คุณจะต้องใช้คำสั่ง "p4 update" เพื่อซิงค์ไฟล์ใหม่แทน "p4 sync" "p4 update" จะตรวจสอบไฟล์สำหรับการเปลี่ยนแปลงก่อนทำการซิงค์

บังคับด่วน

ตัวอย่างต่อไปนี้ทั้งหมดจะผ่านทางบรรทัดคำสั่ง

1) กำหนดค่าการเชื่อมต่อของคุณกับ Perforce

export P4USER=matt
export P4CLIENT=demo-workspace
export P4PORT=perforce:1666

คุณสามารถติดการตั้งค่าเหล่านี้ในไฟล์ shell config ของคุณใช้p4 setเพื่อบันทึกการตั้งค่าในWindows และ OS X หรือใช้ไฟล์ Perforce config

1) สร้างพื้นที่ทำงาน

p4 workspace

# set your root to where your files should live:
Root: /Users/matt/work

# in the resulting editor change your view to map the depot files you care about
//depot/main/... //demo-workspace/main/...
//depot/dev/...  //demo-workspace/dev/...

2) รับไฟล์จากเซิร์ฟเวอร์

cd /Users/matt/work
p4 sync

3) ชำระเงินไฟล์ที่คุณต้องการทำงานและแก้ไข

p4 edit main/foo; 
echo cake >> main/foo

4) ส่งไปยังเซิร์ฟเวอร์

p4 submit -d "A trivial edit"

5) เรียกใช้p4 help simpleเพื่อดูคำสั่งพื้นฐานที่คุณจะต้องใช้กับ Perforce

ความแตกต่างที่ยิ่งใหญ่ที่สุดระหว่าง git และ p4 ซึ่งไม่มีที่อยู่คำตอบที่มีอยู่ก็คือพวกเขาใช้หน่วยนามธรรมที่แตกต่างกัน

• ในคอมไพล์สิ่งที่เป็นนามธรรมคือแพทช์ (aka diff, aka changeset) การคอมมิตในคอมไพล์คือเอาต์พุตของการรันdiffระหว่างสถานะก่อนหน้าและสถานะปัจจุบันของไฟล์ที่ถูกคอมมิต
• อย่างเลี่ยงไม่พ้นในนามธรรมเป็นไฟล์ การคอมมิทใน p4 เป็นเนื้อหาทั้งหมดของไฟล์ในการคอมมิท ณ เวลานั้น สิ่งนี้ถูกจัดระเบียบเป็นรายการการเปลี่ยนแปลง แต่การแก้ไขจะถูกจัดเก็บแบบต่อไฟล์และรายการการเปลี่ยนแปลงจะรวบรวมการแก้ไขไฟล์ต่าง ๆ เข้าด้วยกัน

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

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

อาจมีเอกสารไม่มากนักเนื่องจาก Perforce เป็นระบบควบคุมการแก้ไขแบบดั้งเดิม (ใกล้กับ CVS, การโค่นล้ม ฯลฯ ) และโดยทั่วไปถือว่ามีความซับซ้อนน้อยกว่าระบบควบคุมการแก้ไขแบบกระจายรุ่นใหม่

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

1. ทำงานp4 editกับแต่ละไฟล์ที่คุณต้องการแก้ไข คุณจำเป็นต้องบอก Perforce ว่าไฟล์ใดที่คุณกำลังแก้ไข p4 addหากคุณกำลังเพิ่มไฟล์ใหม่ใช้ p4 deleteหากคุณลบไฟล์ที่ใช้
2. ทำการเปลี่ยนแปลงรหัสของคุณ
3. เรียกใช้p4 changeเพื่อสร้างเซ็ตการแก้ไข ที่นี่คุณสามารถสร้างคำอธิบายการเปลี่ยนแปลงของคุณและเลือกที่จะเพิ่มหรือลบไฟล์ออกจากเซ็ตการแก้ไขของคุณได้เช่นกัน คุณสามารถเรียกใช้p4 change CHANGE_NUMBERเพื่อแก้ไขคำอธิบายได้ในภายหลังหากจำเป็น
4. คุณสามารถทำการเปลี่ยนแปลงรหัสเพิ่มเติมได้ถ้าต้องการ หากคุณจำเป็นต้องเพิ่ม / แก้ไข / ลบไฟล์อื่น ๆ p4 {add,edit,delete} -c CHANGE_NUMBER FILEที่คุณสามารถใช้
5. เรียกใช้p4 syncเพื่อดึงการเปลี่ยนแปลงล่าสุดจากเซิร์ฟเวอร์
6. เรียกใช้p4 resolveเพื่อแก้ไขข้อขัดแย้งจากการซิงค์
7. p4 submit -c CHANGE_NUMBERเมื่อคุณพร้อมที่จะส่งการเปลี่ยนแปลงของคุณทำงาน

คุณสามารถใช้p4 revertเพื่อยกเลิกการเปลี่ยนแปลงไฟล์ของคุณ

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

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