[phobos] phobos commit, revision 2028

[Steve Schveighoffer]

----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Thu, September 23, 2010 12:28:24 PM
> Subject: Re: [phobos] phobos commit, revision 2028
> 
> On 9/21/10 11:24 CDT, Steve Schveighoffer wrote:
> > But I've been following  this discussion quietly, and I don't really 
>understand
> > the objection to  checking in changes that break other builds.  It's not 
like
> >  checking in changes is a release, so it has no bearing on people who  
aren't
> > actively developing phobos/druntime.  Isn't it enough for  Brad's automated
> > builds to maybe just post an email to this list when a  build fails (after 
he
> > changes it to be triggered by checkins of  course)?  And then it's just on 
>the
> > developer to make sure it works  on his system at least (shame on you if you
> > checkin a change that wasn't  tested in at least *one* system).  In other 
>words,
> > why should each  developer check all builds when we have an automated system 
>that
> > does  that?
> 
> The idea is that the trunk should be clean such that people can  rebase their 
>code freely to benefit of the latest source and avoid conflicts  when checking 
>in. The current system discourages synchronization. Even with the  automated 
>build in place, and even if we know that yesterday's build succeeded,  there's 
>no info whether the build would work with whatever is in the trunk.  Ideally the 
>cycle is change code -> make sure it builds ->  commit.

That would be ideal, but not everyone has a mac, a windows box, and a Linux box 
(and what about freeBSD?).  And even if they did, to require them to check the 
build on all three before checking in would be quite tedious (you can't just svn 
update because you haven't checked in yet!).

If you check in a change that builds on nothing, then yeah, that's an obvious 
problem.  But I don't think we should attach so much negativity to checking in a 
change that breaks a build by accident -- nobody is purposely checking in broken 
code.  Branches are usually for when you know you are going to be working on 
something for a while and may check in incomplete or non-functioning code.

Note, you are free to rebase your code from a specific version -- which can be 
determined by the last valid build from Brad's server (in fact, Brad, you could 
tag the 

latest successfully tested build automatically).

-Steve