trunk คือที่เก็บ code หลักของเรา
ส่วน branches ใช้ในกรณีที่ต้องการทดลอง feature บางอย่าง (ที่แยกออกไปเพราะไม่ต้องการให้กวนกับ code หลักที่คนอื่นๆกำลังทำงานอยู่) ส่วน tags ใช้ในการ mark version ที่ release ออกมา เพื่อให้สะดวกกับการแก้ bug

style การใช้งาน branches กับ trunk มีอยู่ 2 พวก
พวกแรก ทุก feature ที่ทำ ให้ทำที่ branches เท่านั้น, พอผ่านการอนุมัติแล้วค่อย merge มาที่ trunk

พวกที่สอง การแก้ code ต่างๆทำที่ trunk เลย, ยกเว้นว่าอะไรที่กระทบเยอะๆ และไม่แน่ใจว่าเป็นทางที่ถูกหรือเปล่า ก็ให้ไปทำที่ branches

trunk, branches, tags เป็น practice ที่เขาใช้กันทั่วครับ, ใช้ตามเขาก็สะดวกดีครับ (จะได้ไม่ต้องปวดหัวหาทางออก เวลาที่จะต้อง release)

ประเด็นอื่นๆที่เกิดกับ subversion ก็มีว่า ถ้ามีหลายโปรเจค เราจะรวมไว้ที่ repository เดียวหรือแยกกันดี, อย่าง apache เขารวมทุก project ไว้ที่ repository เดียว เลข revision มันก็เลยวิ่งไม่หยุด,
ส่วนการแยกโปรเจค ก็มีประเด็นว่า ต้องคอย setup repository อยู่เรื่อยๆ

ของผมทำเป็น server กลางเอาไว้ทดสอบ แล้วเวลาแก้ไข Code ก็ commit ขึ้นไปที่ server เหมือนกัน แทบไม่มี database หรือ apache อยู่ที่ local ของแต่ละคนเลย อย่าเข้าไปอ่านนะ บทความของ Rookie

ปัญหาหลักๆก็คือ dataset + schema ของ database ที่ต้อง maintain , ใน framework ใหม่ๆเดี๋ยวนี้เขามีตัวทีเรียกว่า migration ที่ช่วยให้เรา maintain schema ของ database ผ่านทาง source file, ทำให้เราสามารถใส่มันไว้ใน version control ได้ด้วย (หรือมองในอีกมุมว่า ตอนนี้ database เราก็มีเลข version แปะไว้ เวลาอ้างถึง database ก็ต้องพูดประมาณว่า ตอนนี้ production database อยู่ที่ revision 80, ส่วน test database อยู่ที่ revision 87)

ในส่วนของผม ถ้า project ไหน ไม่ได้ใช้ framework แบบที่มี migration, ผมก็จะกำหนดให้ developer ที่ต้องการแก้ไข schema ให้เขียน script ที่จะไป alter หรือ create table และกำหนดวิธีตั้งชื่อด้วย โดยให้มี running number อยู่ในเลขด้วย เพื่อที่เวลา setup database จะได้ run script พวกนี้ตามลำดับที่ถูกต้อง (script พวกนี้เก็บอยู่ใน repository ด้วย)

ลองศึกษา concept ของ migration ของ rails ดูก็ได้ครับ, ผมลอกแนวทางจากตัวนั้นแหล่ะ

ตอนนี้ผมใช้ drupal ในการทำเว็บ ทีนี้ data (ที่อยู่ใน database) มันมากกว่า code แต่ผมก็ยังอยากจะทำ version control อยู่ดี เพราะว่ามันจะได้ deploy ง่ายประมาณนี้น่ะครับ

ก็ยังมึน ๆ อยู่ว่าจะทำอย่างไรดี ไม่รู้มีใครมีท่าดี ๆ บ้าง

ที่ผมทำอยู่คือก็เขียน script ไว้ให้ dump database มา (ได้ใหญ่มาก) แล้วจับใส่ version control มันทั้งก้อนเลย ซึ่งทดลองแล้วเวลา diff มันเละเทะมาก สุดท้ายเลยจับ zip ก่อน ก็เลยเหมือนเก็บ binary file ไว้เท่านั้นเอง รู้สึกว่าใช้งาน version control ไม่คุ้มเลยครับ

• ตอนนี้ผมใช้ GIT อยู่ครับ รู้สึกว่าชอบมากกว่า SVN
• ที่ทำงานมีเครื่องสำหรับทดสอบ แต่ก็แยกกับเครื่องที่เก็บ Repositories (อายนิดนึง ถ้าจะบอกว่าใช้ MacMini เป็น Servers)
• ในแล็บท็อปก็ใช้ MAMP สำหรับการพัฒนา, ฉะนั้น ก่อนกลับบ้าน ถ้าอยากให้เวอร์ชันล่าสุดไปด้วย ก็ต้อง Fetch เอาโค้ดล่าสุดและ Export database ไปด้วย
• ลอง GIT ดูหน่อยมั๊ยครับ ถามพี่ pphetra ก็ได้ครับ ว่ามันดียังไง

ตอนนี้ผมก็ใช้ svn โดยใช้ร่วมกับ trac อยู่ โดยโปรเจคทั้งหมดเป็น php cms อยากลองใช้ version control ตัวอื่นๆ เหมือนกัน แต่ติดอยู่ตรงที่ trac support อยู่แค่ svn ในขณะนี้ครับ

ตอนนี้ก็มีปัญหาตรงเรื่อง database ว่าจะทำเรื่องอย่างที่คุณ pphetra ว่ามาได้อย่างไรอยู่ครับ ว่าจะเอาเรื่องนี้ไปพูดคุยตอน BarCamp 3 เหมือนกัน :D

I will change the world, to the better day.

ผมเชียร์ทาง Bazaar ครับ setup ตัว repository ง่ายมาก คือมี ssh(ต้องลง bzr ที่ server)/sftp(ไม่ต้องลง bzr ที่ server)/ftp แล้วก็ push ไปได้เลย ไม่ต้องกดสร้างอะไรก่อนครับ(มันจะสร้าง folder ไปเอง) แต่ที่ไม่ชอบคือยังทำ virtual user ไม่ได้ครับ(ถึงมี hosting ผูกขาดเจ้าเดียว) สำหรับการใช้กับ pm ผมใช้ redmine ก็ใช้ได้ครับ Trac ก็มี plugin