เหตุผลเฉพาะสำหรับยังคงใช้การโค่นล้ม? [ปิด]

22

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

ปิดให้บริการใน7 ปีที่ผ่านมา

ฉันต้องการเลือกระบบควบคุมเวอร์ชันสำหรับ บริษัท ของฉัน จนถึงตอนนี้ฉันรู้ว่าฉันมี Git, การโค่นล้มและ Mercurial

ทุกวันนี้ฉันเห็นว่า Git นั้นถูกใช้มากที่สุดดังนั้นฉันจึงสงสัยว่าจะมีเหตุผลใดที่จะยังคงใช้การโค่นล้มหรือฉันควรไปที่ Git โดยตรงหรือไม่

version-control git svn

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

36

พวกเขาทั้งสองทำงาน สิ่งสำคัญคือว่าพวกเขาจะตอบสนองความต้องการของคุณซึ่งคุณไม่ได้บอกเรา

— แมทธิวฟลินน์

6

ดูเหตุใดจึงใช้ SVN มีข้อดีที่ซ่อนอยู่ (มากกว่า GIT / Mercurial / Bazaar) ที่นั่นไหม? บน Stack Overflow

— Detly

11

คุณโต้แย้งการรวม Mercurial ใด?

— mouviciel

8

-1 สำหรับถ้อยคำ (baiting IMHO) และ "วันนั้นฉันเห็นว่า Git นั้นถูกใช้มากที่สุด" - Git เป็นเรื่องธรรมดามากในโลกที่มาเปิด แต่ในพื้นที่ขององค์กรก็มากหายาก Corps ชอบความคิดของแหล่งเก็บข้อมูลส่วนกลางส่วนกลางที่เชื่อถือได้และเปลี่ยนแปลงได้ช้ามาก ในพื้นที่ขององค์กรคุณมีแนวโน้มที่จะเห็น CVS ที่ดีกว่า SVN แม้ไม่เคยสนใจ DVCS

— Keith

4

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

— Keith

46

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

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

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

— Mason Wheeler
แหล่งที่มา

16

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

— โจอาคิมซาวเออร์

8

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

— ร่าเริง

21

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

— Jan Hudec

18

การควบคุมเวอร์ชันแบบกระจายไม่ใช่ "แฟชั่น" มันเป็นวิวัฒนาการของการควบคุมแหล่งที่มาเช่นเดียวกับการควบคุมเวอร์ชันที่เกิดขึ้นพร้อมกันนั้นเป็นวิวัฒนาการเหนือกระบวนทัศน์การล็อกไฟล์

— JesperE

6

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

— SK-logic

19

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

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

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

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

นี่เป็นจุดที่ดี ฉันคิดว่าหนึ่งในเหตุผลที่คน preffer Git มากกว่า SVN คือ Git มีเครื่องมือ CLI ที่ดีกว่า แต่สิ่งนี้สามารถชดเชยได้ด้วย SVN GUI บุคคลที่สามที่ดีเช่น TortoiseSVN บน Windows

— ร่าเริง

2

นี่คือหนึ่งในเหตุผลที่เราไป Mercurial (และ TortoiseHg) เหนือ Git ข้อดีของการควบคุมเวอร์ชันแบบกระจายและการใช้เครื่องมือที่เหมาะสมและการรวม IDE

— HappyCat

15

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

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

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

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

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

1

นี่เป็นสิ่งที่สงสัย แต่จริง ๆ แล้วคอมไพล์ต้องการเพียงแค่ส่วนใหญ่ของแฮชเท่านั้นที่จะสามารถแก้ปัญหาได้โดยทั่วไปบางสิ่ง ~ 6 ตัวอักษรก็เพียงพอแล้วไม่ใช่แฮชทั้งหมด

— TC1

2

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

— JesperE

1

@JesperE: ใช่ แต่หมายเลขรุ่น SVN เพิ่มขึ้นตามลำดับเมื่อเวลาผ่านไปในขณะที่ Git ของแฮชแม้ว่าคุณจะย่อให้ย่อก็อาจจะสุ่ม

— Keith Thompson

2

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

อาจมีข้อดีบางประการสำหรับ SVN ทั้งนี้ขึ้นอยู่กับสถานการณ์

(สิ่งนี้ยังมีข้อเสียใหญ่ ๆ เช่น ".svn" ขยะที่ซ่อนอยู่ตลอดจนโฟลเดอร์ต้นไม้ของคุณ)

— Richard Nichols
แหล่งที่มา

3

หมายเหตุ: ไม่มี. svn ขยะตั้งแต่ v1.7 - ตอนนี้ทั้งหมดถูกเก็บไว้ในที่เดียว

— gbjbaanb

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

— Benubird

2

"ถ้าคุณมีงานที่สามารถทำได้ในหกชั่วโมงมันจะดีกว่าถ้าเขียนเครื่องมือที่ทำได้ใน 20 นาทีแม้ว่าการสร้างเครื่องมือจะใช้เวลาหกชั่วโมงหรือไม่"

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

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

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

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

แก้ไข ข้อดีของ GIT ผ่าน SVN

~~ไม่จำเป็นต้องใช้เซิร์ฟเวอร์เฉพาะที่~~ จริงแล้วทั้งคู่สามารถใช้เซิร์ฟเวอร์ w / oa ได้
สามารถพัฒนาต่อไปได้แม้ไม่มีการเชื่อมต่อเครือข่าย
การจัดการสาขาง่ายกว่ามาก
การสนับสนุนที่ดีขึ้นจากเครื่องมือ CI เช่น Bamboo

มีคนพูดถึงเครื่องมือ (สำหรับ visual studio) ว่าเป็นเหตุผลที่ต้องใช้ SVN http://gitscc.codeplex.com/ให้การสนับสนุน GIT สำหรับ Visual Studio

— Apeirogon Prime
แหล่งที่มา

6

SVN ไม่จับไบนารีไฟล์ที่ดีกว่าแล้ว Git หรือปรอท

— ชื่อปลอม

2

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

— njr101

2

Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.ฉันไม่เห็นด้วยกับสิ่งนี้อย่างสมบูรณ์ มันอาจมีประโยชน์บางอย่างที่รับรู้ในบางสถานการณ์ แต่บางสิ่งที่ง่ายเหมือนหมายเลขรุ่นใน svn ที่มนุษย์สามารถอ่านได้เป็นประโยชน์อย่างมากในหลาย ๆ องค์กร

— TZHX

1

@apeirogon - ทุกอย่างจะเกิดขึ้นกับสิ่งที่คุณจะใส่ในที่เก็บ HEAD โดยลำพังหนึ่งในที่เก็บหลักที่ฉันทำงานด้วยคือ 11.1 GB! ถ้าฉันมีมันใน Git / bzr / hg repo มันอาจจะใช้เวลา 100+ GB

— ชื่อปลอม

1

แน่นอนว่าเป็นเพราะ repo นี้เต็มไปด้วยไฟล์ PCB และโมเดล 3 มิติซึ่งเป็นไบนารีทั้งหมดในรูปแบบและมีพื้นที่ไม่มากนัก คำแนะนำที่นี่ (Electronics.SE เช่นสำหรับคนที่เก็บไฟล์ PCB ddesign เป็นต้น) นั้นแตกต่างกันมากถ้าหากมีคนเก็บซอร์สโค้ดไว้

— ชื่อปลอม

1

จะมีเหตุผลใดที่เจาะจงที่จะใช้การโค่นล้มในสมัยนั้น

นอกเหนือจากการสนับสนุนการใช้เครื่องมือใน IDE (ซึ่งฉันไม่ได้ใช้) - ไม่จริงไม่ แน่นอน SVN อาจจะคุ้นเคยมากกว่า แต่นั่นเป็นเพียงเหตุผลเดียวและฉันพบว่าทั้ง Hg และ Git นั้นง่ายมาก (และเร็วมาก) ในการเรียนรู้

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

ฉันไม่เข้าใจสิ่งนั้น แต่คุณรู้อะไรไหม? มันไม่สำคัญ คุณไม่จำเป็นต้องรู้สิ่งใด ๆ ในการใช้ Git

ส่วนใหญ่แล้ว Git และ Hg นั้นใช้งานง่ายและมีข้อได้เปรียบเหนือ SVN แน่นอนว่าช้างในห้องนั้นแตกแขนงแล้วกิ่งก้านก็ทำงานใน Git และ Hg ในทางตรงกันข้ามใน SVN พวกเขาเจ็บปวดอย่างที่สุดและแตกหักอย่างรุนแรง (รวมหลายหัว)

แน่นอนคุณยังสามารถใช้ SVN ได้ คุณยังสามารถใช้ Windows XP ได้ อย่างไรก็ตามผู้ใช้ส่วนใหญ่ที่ลองใช้ทั้งคู่ตกลงกันว่าหนึ่งในทางเลือกนั้นเหนือกว่าอย่างมาก

¹ใช่ฉันเข้าใจแล้วว่านี่เป็นเรื่องตลก ฉันคิด.

— คอนราดรูดอล์ฟ
แหล่งที่มา

การสอน Git กับการทำแผนที่เอนโดมอนิฟิ endofunctors การทำแผนที่ย่อยของพื้นที่ฮิลแบร์ต? ฉันต้องอ่านมัน! แต่ไม่ได้นี้ค่อนข้างนำไปใช้กับ Darcs ซึ่งถูกเขียนใน Haskell (ซึ่งผมคิดว่าendofunctorหมายถึง) และแรงบันดาลใจจากกลศาสตร์ควอนตั (เพราะฉะนั้นHilbert พื้นที่ )? ฉันไม่เห็นว่า Git และ HG เกี่ยวข้องกับสิ่งเหล่านี้อย่างไร

— leftaroundabout

@leftaroundabout มันเป็นเรื่องตลก คำอธิบายไม่ถูกต้อง (เท่าที่ฉันรู้) มันเป็นเรื่องยากสำหรับบทเรียนจำนวนมากที่เริ่มต้นด้วย "กิ่งก้านสาขานั้นง่ายเมื่อคุณรู้ว่า ... " จากนั้นก็มีคำอุปมาเฉพาะโดเมนที่ซับซ้อนหลังจากนั้น

— Konrad Rudolph

1

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

— Mason Wheeler

1

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

— Mason Wheeler

3

@ KonradRudolph การรวมสาขากลับเข้าที่ลำต้นทำงานได้ดีใน SVN รุ่นล่าสุด มันเริ่มดีขึ้นเรื่อย ๆ เป็นเวลาหลายปีจนถึงตอนนี้ซึ่งมันก็ดีมาก

— Adam Bruss