[sldev] Version control repository

[Rob Lanphier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

Interest in the topic of a version control repository seems to have
died down a bit, I'm sure in no small part due to alternatives now
available.  I plan to eventually pursue a Subversion repository setup,
per the specs below, but not as aggressively as I was thinking last week.

My thinking now is that there's a lot of work to do to get JIRA set up
in a really functional way, and to do a better job staying on top of
it.  There's a lot of work that needs to go into both configuring the
system and organizing what's been submitted.  Until we can get some
more people hired to help out (he says, casually linking to
http://lindenlab.com/employment ), there's only so much we'll be able
to take on.

Release management is also going to be a short-term goal.  As stated
earlier, I'd like to make sure that we synchronize source and binary
releases, such that it's easy to get the source code corresponding to
a binary release.  That /may/ lead us right back to a public revision
control system, but I doubt it.  Having easy to download tarballs is
also important in my experience; it's probably more important to get
that right than it is to get version control right.

So, barring any eloquent and compelling objections, I'm going to put
this on the back burner for a little bit.

Thanks
Rob

On 1/12/07 5:27 PM, Rob Lanphier wrote:
> Hi all,
>
> I'm running out of time to get done with everything I wanted to
> this week, but I want to give a quick summary of where we're at
> with respect to version control:
>
> *  Timeframe:  I don't want anyone to get /too/ excited about
> getting this right away.  I'm guessing (not promising) that this is
> at least two months out, and that could be optimistic.  We've been
> taken aback by how quickly the community has come up to speed on
> the codebase and is already starting to submit patches...we
> expected to have more time to sort this out. *  My reading of this
> mailing list is that consensus is leaning pretty heavily toward
> Subversion.  A lot of the chatter on IRC and in-world has been
> pro-Mercurial, with a bit of both on the wiki:
> https://wiki.secondlife.com/wiki/Talk:Version_control_repository
>
> Linden Lab's internal discussion on the topic leans heavily toward
> Subversion, though it's also clear that "happy" may not be the best
>  word to describe the general feeling toward it; "learned to live
> with" may be more accurate.  The suggestion was also made to let
> the community continue to run unofficial repositories for a while
> (see below) until a clear winner shakes out.  My personal leaning
> on this is now toward Subversion if I had to pick between the two
> (assuming I don't take the suggestion to punt).  Mercurial looks
> harder to support, and in general still seems a little too rough
> around the edges.
>
> *  I didn't do a very good job of stating the requirements for the
> system, and the options we have there.  Here are the two modes of
> operation:
>
> MODE #1:  read-only, "official" repository with occasional source
> drops from internal SVN repository pushed externally MODE #2:
> read-only, "official" repository which mirrors/pushes internal SVN
> outbound
>
> The assumption at Linden Lab has been something along the lines of
> mode #1.  I realize mode #2 is far more useful, but the LL dev
> staff isn't ready for that.  One option we have is to wait until LL
> dev's staff /is/ ready for operating in mode #2 before putting out
> a repository, since mode #1 is really just a glorified tarball push
>  anyway.
>
> *  It's clear people are hoping for Linden Lab to provide
> write-access to at least sandbox branches.  There is some appeal to
> that (being that we can grant commit access to developers who sign
> contribution agreements, and make it clear that all commits are
> contributions). This is a tougher nut to crack, however; this ups
> the ante on operational complexity and any number of other issues.
> This is not something we were planning to do, but could still be
> convinced to do. Current plan of record: no sandboxes.
>
> *  For those who can't wait for an official repository, there's an
> unofficial repository at http://opensecondlife.org , not run by
> Linden Lab or affiliated with us in any way.  We're excited to see
> the enthusiasm embodied by this effort, and it looks like there's
> already some great work cooking there.  Based on in-world meeting
> yesterday, there's a desire to get that stuff checked in to the
> official Linden Lab distribution, which can work /if/ we all handle
> things correctly. There needs to be very careful accounting of who
> contributed what, and we want to be sure it's very clear that the
> person who wrote the code is truly contributing their work to us
> under the contribution agreement, and that they are receiving
> proper credit for their work.
>
> Plan of record in summary: Timetable: uncertain...still need solid
> requirements, probably at least a couple months away Technology:
> Subversion Mode of operation: Read-only access with occasional
> pushes (Mode #1 above) Write access sandboxes:  no
>
> So, I'd like to make a decision by Wednesday of next week, getting
> a better spec in place on the wiki, getting these two questions
> answered by then: 1.  Is that plan of record useful enough to
> satisfy the vague appetite for version control, or is that not
> enough to be worth it? 2.  If you believe that an official Linden
> Lab source repository needs to be more ambitious, are you willing
> to wait longer to get that result?
>
> Please make your opinions known here or on the wiki talk page.
> I'll be holding office hours in world at Grasmere(112, 81, 26) (the
> cubicle on the hill) on Monday at 3pm and Wednesday at 9am if you
> have questions (and will post those on my wiki user page).
>
> Thanks Rob
>
>
> On 1/9/07 10:58 PM, Rob Lanphier wrote:
>> Hi everyone,
>
>> A hot topic on IRC, in-world, and everywhere else seems to be "is
>>  Linden Lab going to provide a version control repository, and if
>>  so, when?"  The answer is "we need a spec first".  What's so
>> hard about that?  Well, I want to work with the community on
>> defining the spec, and come up with something that is going to be
>> the most useful for everyone.
>
>> The options are spelled out here:
>> http://wiki.secondlife.com/wiki/Version_control_repository
>
>> ...as are some of the discussions (hit the "discussion" tab to
>> view).
>
>> The safe option these days is Subversion.  It's really widely
>> supported, has a ton of tools for all platforms, and really seems
>>  to have hit critical mass.  We use it internally, and as near as
>> I know, everyone seems reasonably happy with it.  There hasn't
>> been any chatter (that I've heard) about replacing it any time
>> soon. The command line is very sensible, and the model is
>> reasonably easy to understand for anyone who has worked with
>> version control systems before.  In particular, the command line
>> interface was designed to be similar (but not slavishly
>> identical) to the venerable CVS. There's also lots of nice tools
>> and extensions that work with it, and I think a reasonable number
>> of IDEs support it now (fact check, aisle 7)
>
>> The trendy thing these days in version control systems is
>> distributed control systems, first popularized by BitKeeper, and
>> more recently made popular by the explosion of options such as
>> git, darcs, svk, bazaar, and Mercurial.  What's interesting about
>> these systems is that they make it much easier for ad hoc teams
>> to collaborate, each developer publishing a mini repository, and
>> provide tools for people to deal with lots of little patchsets
>> from a lot of different sources.  These tools aren't as mature as
>>  Subversion, but they are much more powerful.  The command line
>> interface on many of these is quite difficult (that's at least my
>>  experience with bazaar), but I've heard good things about
>> Mercurial, and looking at the quick start guide, it seems the
>> most intuitive of the open source options.  Svk is also
>> interesting, as it's layered on top of Subversion (more below on
>> why that can be good).
>
>> While Subversion works great for, say, a team of professional
>> developers all in the same building working under the same
>> management on the same or at least coordinated set of projects,
>> it isn't as well suited to collaboration of a lot of developers
>> each working on their own pet feature that want to pick and
>> choose which other developers they want to collaborate with.
>> Dealing with branches gets really tedious really quickly...get
>> above a dozen, and you've got a bit of a nightmare.  Merging
>> tools are o.k....certainly better than CVS, but things are much
>> easier when everyone stays on the same branch.
>
>> Subversion would be nice choice because that's what Linden Lab
>> uses internally.  Reducing drag on LL developers is an important
>> consideration; in addition to my selfish motive to maintain a
>> good relationship with my co-workers, I want to have as few
>> mental or logistical obstacles for LL developers to work on the
>> open source side of the firewall.
>
>> Mercurial is interesting to me, because it seems like a great
>> blend of distributed system and sensible interface.  My knowledge
>> of Mercurial is a little thin, though, so I'd be interested in
>> hearing from people who have spent quality time with it.
>> Mercurial might be intriguing for LL devs, and the open source
>> repository may be seen as a great way to try it out and maybe
>> even get religion on distributed revision systems.  However, it
>> may be yet another friggin' half-working tool to learn the quirks
>> for.  Hard to say; the devil is probably in the details.
>
>> Svk might be a great compromise between the two.  However, I have
>>  no real experience with svk either.
>
>> The community seems divided on the issue.  One in-world
>> discussion at Hooper was leaning pretty heavily toward a
>> distributed tool like Mercurial.  Another discussion at Pooley
>> after the town hall wound down seemed to be a much more
>> Subversion-leaning crowd.
>
>> I'm truly on the fence on this topic, perhaps leaning slightly
>> toward Mercurial, because I think a distributed system would be a
>>  better fit.  I am interested in having a conversation about this
>>  before making a decision.  Whatever we decide, I want to stick
>> with it for a couple of years at least, so let's make sure we do
>> enough homework to avoid buyer's remorse.
>
>> Thoughts?
>
>> Rob
>
>
> _______________________________________________ Click here to
> unsubscribe or manage your list subscription:
> /index.html
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFrye9Pd430ImZiAMRApRaAJ4jp3g6bx1iS7yIIAzz5ujLPVIx0wCfU8nH
+R1snTB0+uu68vvahMsQmCQ=
=7Jv0
-----END PGP SIGNATURE-----