การควบคุมเวอร์ชันสำหรับการทำงานร่วมกัน (ที่มีระดับคำต่างกัน)


20

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

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

ถ้าไม่เช่นนั้นฉันยินดีรับข้อเสนอแนะอื่น ๆ ที่อ้างอิงจากประสบการณ์ (ลองหลีกเลี่ยงการเก็งกำไรโปรด)

ฉันกำลังคิดถึง Git, Subversion, Mercurial, darcs หรือ Bazaar ตั้งขึ้นเพื่อจัดการความแตกต่างระดับคำกับ wdiff พร้อมกับวิธีการตั้งค่าการเข้าถึงที่ปลอดภัยด้วยกุญแจสาธารณะ (เช่นผ่าน ssh) อย่างไรก็ตามไม่มีผู้ให้บริการควบคุมเวอร์ชันที่ฉันดูที่ดูเหมือนจะเสนออะไรเช่นนี้ สำหรับการทำงานร่วมกันทางวิทยาศาสตร์คุณสมบัติ "ระดับองค์กร" ที่เน้นโดยหลาย บริษัท เหล่านี้ไม่ได้สำคัญมาก (มีสาขาจำนวนมากการรวมเข้ากับ trac การตรวจสอบโดยบุคคลที่สามทีมงานโครงการลำดับชั้น) แต่ความแตกต่างระดับคำดูเหมือนสำคัญ แต่ยังไม่ได้รับการสนับสนุน จากประสบการณ์ของฉันด้วยระดับบรรทัดแตกต่างกันสำหรับไฟล์ข้อความทุกคนต้องหลีกเลี่ยงการจัดรูปแบบย่อหน้าและตัวแก้ไขที่เปลี่ยนแท็บเป็นช่องว่างหรือในทางกลับกันทำให้เกิดปัญหา ดูเหมือนว่าจะมีความขัดแย้งในการแก้ไขปลอม ๆ

ดูคำถามที่เกี่ยวข้องที่ MO เกี่ยวกับเครื่องมือสำหรับการทำงานร่วมกันและคำถามที่เกี่ยวข้องมากกว่าที่ TeX.SE เกี่ยวกับการควบคุมเวอร์ชันสำหรับเอกสารน้ำยางและแพคเกจสำหรับการควบคุมน้ำยางรุ่น ดูตารางเปรียบเทียบการตรวจสอบ SVN Hostingสำหรับรายชื่อผู้ให้บริการโฮสติ้งจำนวนมากสำหรับระบบควบคุมเวอร์ชันหลักเพียงระบบเดียว


แก้ไข:คำตอบของ Jukka Suomela สำหรับคำถาม TeX.SE "เครื่องมือLaTeX ที่ทราบดีที่สุดและผสานการโค่นล้มสำหรับการโค่นล้ม " ดูเหมือนจะเป็นคำแนะนำที่ดีที่สุดจนถึงการครอบคลุมวิธีตีความ delta ในระดับคำ ยิ่งไปกว่านั้น Jukka ได้อธิบายว่าความแตกต่างระหว่างรุ่นต่อเนื่องที่ปลายพื้นที่เก็บข้อมูลนั้นแยกจากความแตกต่างระดับผู้ใช้ที่ใช้สำหรับการตรวจจับความขัดแย้งและการรวมการเปลี่ยนแปลง คำตอบของ Jukka ที่ TeX.SE ไม่รวมการแก้ไขและการรวมพร้อมกันโดยอาศัยโทเค็นการแก้ไขอะตอมแบบดั้งเดิมแทนเพื่อหลีกเลี่ยงการแก้ไขข้อขัดแย้ง การชี้แจง (และแก้ไข) คำถามเดิมของฉันมีวิธีที่จะทำให้แน่ใจว่าการแก้ไขข้อขัดแย้งสามารถแก้ไขได้บนพื้นฐานของความแตกต่างของคำแทนที่จะเป็นพื้นฐานของความแตกต่างของบรรทัดหรือไม่? ในคำอื่น ๆ สามารถwdiffหรือเครื่องมือที่คล้ายกันถูกรวมเข้ากับส่วนการตรวจจับความขัดแย้งของเครื่องมือควบคุมเวอร์ชันคล้ายกับวิธีสิ้นสุดความแตกต่างและความแตกต่างในช่องว่างของช่องว่าง


3
ฉันไม่ค่อยเข้าใจคำถาม ตัวอย่างเช่นใน SVN diffs ที่แสดงต่อผู้ใช้จะถูกสร้างขึ้นโดยไคลเอนต์และขึ้นอยู่กับไคลเอนต์ SVN ของคุณ (และการกำหนดค่า) ว่าคุณจะได้รับ diffs ตามคำหรือ diffs ตามบรรทัด บริษัท ที่โฮสต์พื้นที่เก็บข้อมูล SVN ของคุณจะไม่มีผลกับสิ่งนี้เลย
Jukka Suomela

2
@suresh หากคุณกำลังแก้ไข (เขียน) เอกสารข้อความมักจะเป็นความเจ็บปวดที่ต้องสแกนทั้งบรรทัดในส่วนต่างเพื่อดูว่ามีคนเปลี่ยนเครื่องหมายจุลภาคหนึ่งรายการ พฤติกรรมที่ถูกต้องมักจะแสดงหน่วยการเปลี่ยนแปลงที่น้อยที่สุด หรือพิจารณาพฤติกรรมหากไม่มีใครใช้ตัวแบ่งบรรทัด จากนั้นการเปลี่ยนคำเดียวจะทำให้ทั้งย่อหน้าแสดงในส่วนต่างสำหรับคุณในการค้นหาการเปลี่ยนแปลงเล็กน้อย
Mark Reitblatt

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

2
@ อังเดรประเด็นของฉันคือการที่ระบบ VC ต้องการเพียงเพื่อให้สามารถสร้างการแก้ไขทั้งสองใหม่ในฝั่งไคลเอ็นต์และไม่น่าแปลกใจที่ระบบ VC ทั้งหมดสามารถทำได้ สิ่งที่คุณต้องการคือยูทิลิตีการผสานสามทางระดับคำ แต่ฉันไม่ทราบเลย (ตัวอย่างเช่น TortoiseMerge และ kdiff3 เป็นแบบ line-based) เมื่อคุณมียูทิลิตีเช่นนั้นระบบ VC ใด ๆ ที่อนุญาตให้คุณระบุยูทิลิตี้การรวมภายนอกจะเพียงพอ (รวมถึง svn, bzr, git, hg ... )
Maverick Woo

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

คำตอบ:


11

ฉันใช้คอมไพล์เพื่อทำงานร่วมกับเอกสารที่เขียนด้วยลาเท็กซ์ คุณจะต้องปฏิบัติตามกฎบางอย่าง:

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

จากนั้นคุณสามารถใช้git diff --color-wordsและgitk --color-wordsเพื่อดูความแตกต่างของคำศัพท์ (ดูบทความนี้คำต่อคำใน Gitเกี่ยวกับวิธีกำหนดค่า git ให้ใช้อัลกอริธึม word-diff เพื่อแสดงบันทึก git diff / git เสมอ)

เพื่อลดการรวมตัวด้วยตนเองฉันสามารถแนะนำให้ใช้ไฟล์แยกต่างหากสำหรับส่วนและส่วนย่อย (ขึ้นอยู่กับขนาดของเอกสารของคุณ)


ฉันจะลองทำสิ่งนี้กับเอกสารของฉันเองดูเหมือนว่าจะเป็นวิธีที่ง่ายที่สุดในการบรรลุเป้าหมายส่วนใหญ่ของฉัน แต่ไม่ใช่ทุกคนที่กระตือรือร้นที่จะทำงานในลักษณะนี้ ...
András Salamon

2
สำหรับคนที่ลังเลที่จะทำงานด้วยวิธีนี้คุณสามารถใช้ TortoiseGit หากพวกเขาไม่ชอบบรรทัดคำสั่ง git ถ้ามันเกี่ยวกับแต่ละประโยคในส่วนของบรรทัดใหม่ตราบใดที่ไม่มีความกว้างของข้อความสูงสุดบังคับนี่ไม่สำคัญเลย (ฉันได้ทำงานในบางโครงการที่ไม่มีกฎดังกล่าว)
Davy Landman

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

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

4

2
น่าเสียดายที่ "แนวปฏิบัติที่ดีที่สุด" ในเอกสารเหล่านี้เป็นสิ่งที่ไม่สามารถบังคับผู้ทำงานร่วมกันได้อย่างแม่นยำ
András Salamon

4

ฉันต้องการสะท้อนผู้อื่นและแนะนำให้คุณนั่งลงและหากลยุทธ์ SVN ที่ดี ฉันใช้ SVN เพื่อโฮสต์โครงสร้าง "การวิจัย" ทั้งหมดของฉัน:

  • การจัดการการอ้างอิง JabRef
  • ดาวน์โหลด PDF
  • บทความ

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

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

จากนั้นเมื่อทำงานกับผู้ทำงานร่วมกันพวกเขาต้องใช้ SVN อย่างชัดเจนด้วย แต่อีกครั้งการลงทุนในการเรียนรู้ไม่คุ้มค่า และด้วยความคิดบางอย่างคุณสามารถมีมันเพื่อให้คุณเข้าถึงไฟล์ jabref แบบอ่านอย่างเดียว (อาจจะผ่านทาง 'ภายนอก' ใน svn)

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

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

- แก้ไข: Infact ผมได้เขียนข้อเสนอดังกล่าวที่นี่: ยุทธศาสตร์ความร่วมมือทางวิทยาศาสตร์ที่มีน้ำยางและ SVN มันเสนอที่จะใช้ประโยชน์จากคุณสมบัติ svn ภายนอกเพื่อให้การทำงานร่วมกันง่ายระหว่างคนที่มีการตั้งค่าที่คล้ายกัน แจ้งให้เราทราบหากต้องการการเปลี่ยนแปลงหรือไม่เหมาะสม


4

ขณะที่อ่านโพสต์ที่ดีของคุณและมองไปรอบ ๆ เพื่อแก้ปัญหาตัวเองฉันสะดุดลงในตัวเลือกที่จะเปลี่ยนแปลง Colorize ในระดับคำใน gitk ดูเหมือนว่าพารามิเตอร์ gitk จะเป็นคุณลักษณะใหม่และ / หรือไม่มีเอกสารเนื่องจากการเติมข้อความอัตโนมัติไม่ได้เสนอให้และหน้าgitkจะไม่แสดงรายการ
นี่คือตัวเลือกที่ฉันพบ:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

คุณสามารถค้นหาอภิปรายหลายในหัวข้อการค้นหาสำหรับ"diff --color คำ" gitk

แก้ไข:
นี่คือสิ่งที่ดูเหมือนว่า ...

ความแตกต่างของสีในระดับคำโดยใช้ gitk


1

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


2
สำหรับฉันดูเหมือนว่า Kaleidoscope เป็นเพียงเครื่องมือ diff ที่ใช้บรรทัดซึ่งนอกจากนี้จะเน้นการเปลี่ยนแปลงภายในแต่ละบรรทัด มันไม่ใช่สิ่งทดแทน wdiff และเพื่อน ๆ คาไลโดสโคปจะสร้างความแตกต่างที่ไม่สามารถอ่านได้เช่นคุณเพียงแค่ย่อหน้าของข้อความและเปลี่ยนการขึ้นบรรทัดใหม่ เครื่องมือที่ใช้ Wdiff เพียงละเว้นการเปลี่ยนแปลงในการขึ้นบรรทัดใหม่
Jukka Suomela
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.