Talk:Version control repository

SVN

I'm happy with a read only SVN.

We are all developers. We can set up our own local SVN if we want a sandbox. Gigs Taggart 15:13, 9 January 2007 (PST)

Agreed. I think our repo should have a struture like....

• /trunk/slviewer/ Root of what we are given. You basically just need to check this one directory out to build the client.
• /tags/slviewer/slviewer-*/ tag of each revision that's distroed by LL as a set, perhaps with it's binaries, and the build outputs. (map files and .asm files anyone?)
• /branches/slviewer/slviewer-*.1/ Branches to deal with bugs that happen once a tag has been made. Any changes fixed on a branch should also be applied to the trunk too.

Kunnis Basiat 18:38, 9 January 2007 (PST)

• Adam Zaius 06:38, 8 January 2007 (PST) votes for SVN
  • Directory structure something like:
    • /trunk -- Only editable by Linden Lab
    • /branches/users/<username>/ -- unlimited permissions by owner/creator for third-party source

Do we want to integrate the VCS with the Second Life authentication? Pluggability of authentication scheme seems like an important axis to consider. --Which Linden 09:27, 8 January 2007 (PST)

Giving users branches in SVN without a degree of trust is dangerous - purging history in SVN is intentionally very difficult, so a single (malicious) user could conceivably use up all the space in the server or host not-so-legal content (even if you svn rm something, it's still in the history). However if the trunk is pure svn, normal users can use things like svk if they want their own branches. --Ginko Bayliss 13:33, 9 January 2007 (PST)

Very good idea to consider (VCS w/ SLA). I would highly recommend sourceforge due to its known ability to handle major traffic; however, we would not have the SLA. Despite that, there are many professional and mature tools that work directly with SVN, for example Subclipse.

I suggest a tier level repository with modes for production, test, and development, and each with their own trunk, branches, and tags. Production is not distributed and is mainly read-only except for the few who update it. Production is updated with, and only from, approved patches from test. Test tier is updated by an approved group of individuals with patches from development tier. Test is not distributed but is not read-only like the production tier. Test is where people go to get latest working patches. It is similar to Debian's mid-tier. Development can be distributed (people can host their own local sandbox), and it is write-enabled by a larger group responsible to merge code. Once code has been basically approved as working in development, it moves to test, so several patches to development may result in only one patch to test, and that would be the same from test to production. Dzonatas Sol 10:04, 10 January 2007 (PST)

Eddy Stryker 13:22, 9 January 2007 (PST) votes against SVN

• Branching/merging capabilities are hacked in, so instead of doing push or pull commands you are looking up revision numbers to figure out when you last backported and where the new merge should start
• No distributed version control like bitkeeper, git, mercurial, etc without using SVK which is a less than ideal solution
• Not designed for very large codebases like Second Life, where branching becomes unbearable
  • To continue on this point, we had to repair the opensecondlife.org svn database over a dozen times while checking in the thousands of files that make up the full codebase. It's centralized atomic nature seems to start falling apart when you have very big commits or similar operations going on and multiple other people are trying to check out
• SVN is a centralized repository system, it's designed to allow a group of people work together on the same codebase. LL would either have to create two million svn accounts, or have someone take account requests and process them, including setting up permissions for each sandbox... it would become a nightmare very quickly. That's why large distributed projects like the Linux kernel used distributed version control. They use Git which is Linux only right now, but Mercurial is proving to be a very good competitor to Git with support for all major operating systems

Kunnis Basiat 22:35, 14 January 2007 (PST)

• While I agree with the fact that branching and merging is a bit wierd in SVN, it was designed that way from the start, it was designed to get around several of the design flaws that were present in CVS, though I agree it's not as intunitive as it should be, it allows for really good tracking, but it's also a bit confusing. LL has been using SVN for a while, so they should be familiar with how version control in SVN works.
• I Find SVN to be really stable.I've never had a problem with SVN, and I've used it for a couple years professionally, and I've been helping my latest company migrate to SVN. The only annoyance I have about SVN is it's lack of an "obliterate" command, which there is a workaround for, and the schedule of an addition of the command. Other then that issue, SVN has been in use for several years, it's a well tested tool, and if any issues arise while using it, it's likley that you can find support for it. I've only had to break out svnadmin once (to deal with the lack of obliterate, and I found a step-by-step on how to do it.)
• SVN is used by KDE. It has both binary and source files, which reflects what we would be checking into OpenSL, and I think that KDE would have more users editing it, and I'm pretty sure it has a larger codebase.
• I don't know what problem you had with your repo. I am using the windows version of SVN, and I took my existing repo that I've used for other projects and checked in all of the slviewer and libs in one big checkin, with no problems. It copied all ~9000 files and 160megs in about 5 mins.
• I agree that LL creating account for every developer is very unreasonable. I think LL should host a repo that only has "gold" code on it, ready for production, with tags for each build. There should not be a sandbox for every developer. I think that we should submit patches to LL that are diffs from the head version of the repo, then a LL employee can apply the patch, then check&verify it works and passes all tests, then finally commit the patch to the repo. What would the process for a LL employee to recieve a change, validate it, and apply it to production be with Mercurial? I don't know enough about it to say what it's like.
• I Agree the lack of a Distributed Version Control sucks, you've got me curious, I want to play with SVK now.

Distributed version control

One reason I really like the distributed version control systems is because it really reduces the need for Linden Lab to be in the business of giving people their own sandboxes. Many of the newer systems are very easy to host, and merging from multiple repositories is much easier. -- Rob Linden 07:25, 8 January 2007 (PST)

Mercurial

Mercurial's claim: Mercurial is a fast, lightweight Source Control Management system designed for efficient handling of very large distributed projects.

---

Baba Yamamoto votes for this.

• No central repository.
• Easier branching and merging.

Darcs

Darcs is something you may want to investigate. I've used it for other projects, and it was simple and effective enough that the less technical folks have actually started using it for their own projects, it is so simple and effective. A possible con would be that it IS written in Haskell.. but that's not that problematic. --Ky Aska 15:59, 8 January 2007 (PST)

We tried using darcs for a while in-house, and really wanted it to work, but it would frequently never finish operations on windows because it would consume too much memory. Phoenix Linden 09:25, 9 January 2007 (PST)

Out of curiosity, how long ago was darcs tried? It might've gotten better since then - though I've heard that performance during conflict resolution is still rather bad. --Ginko Bayliss 16:32, 9 January 2007 (PST)

Don and Kelly Linden experimented with darcs between 2006.02 and 2006.03. The version was 1.0.2 on linux. The Win and Mac versions may have been different. The conclusion was that darcs could not yet handle large repositories. -- Andrew Linden 2006.01.10 09:21 (PST)

Bazaar

Bazaar seems to be the hot VCS of choice now days, might be worth considering. Not sure if the development model is applicable to SL or not. It's got quite a lot of buzz recently in the Linux/Ubuntu/Launchpad world, also seems to have Windows support. http://bazaar-vcs.org/

Might also be worth looking at using launchpad itself which includes the Bazaar VCS, bug tracking and other stuff, The back end is closed currently but Canonical might be quite happy to allow Linden labs to have a copy of it to host, Mark Shuttleworth recently post about SL http://www.markshuttleworth.com/archives/72 although it would probably be quite a lot of work to setup and the features like bug tracking might be duplicated with existing systems used by Linden (although it seems like it would be fairly easy to integrate them. --Hegemon Skall 13:32, 26 January 2007 (PST)

Comparisons

Thought these might be useful, basically a list of features supported by each VCS:

http://bazaar-vcs.org/RcsComparisons http://en.wikipedia.org/wiki/Comparison_of_revision_control_software --Hegemon Skall 17:38, 27 January 2007 (PST)