[sldev] Version control repository

Tleiades tleiades at hotmail.com
Sat Jan 13 02:12:48 PST 2007


Hi

I don't think the differences between 1 and 2 will influence my work in any 
significant way.

The important thing to me is to get access to the fixes and improvents made 
by others, and incorporate that into my own work.

This can be done either way, as long as the interval between upates to the 
"tarball" is reasonaly - what ever that means - frequent, I'm happy.

So count my vote as an "aye to #1"

/Tleiades
----- Original Message ----- 
From: "Rob Lanphier" <robla at lindenlab.com>
To: "Rob Lanphier" <robla at lindenlab.com>
Cc: <sldev at lists.secondlife.com>
Sent: Saturday, January 13, 2007 2:27 AM
Subject: Re: [sldev] Version control repository


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
>
> iD8DBQFFqDWaPd430ImZiAMRAt/eAJ9AvhyX4bgbOJb1eHLhZqvGpzLoPACeIMSl
> 7HB1WeReSi1Qfk3yLIcHBYA=
> =MIOG
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
> 



More information about the SLDev mailing list