We could actually use Git in a SVN-like way, and have a central repository like we have now.  Then there wouldn't be need for an integrator, everyone can commit stuff themselves.  Git would still make it a lot simpler to share and test code *before* it is committed to trunk, and its branch/merge capabilities seem superior to SVN's.

-Lars



On Wed, 2010-05-26 at 07:24 -0700, Sean Kelly wrote:
> I like Git in theory but I'd prefer people simply be responsible when making changes then put myself in the position of integrator. We're all overworked as it is.
> 
> That said, the Git model works well for having a staging area where a build occurs and unit tests are run automatically for each commit before puishing to the central repo. I've used this model at work in the past and it's great, though a lot of setup is involved.
> 
> Sent from my iPhone
> 
> On May 26, 2010, at 2:19 AM, Lars Tandle Kyllingstad <lars at kyllingen.net> wrote:
> 
> > Was: Re: [phobos] phobos commit, revision 1553
> >
> >
> > On Tue, 2010-05-25 at 09:32 -0500, Andrei Alexandrescu wrote:
> >> I'd vote one up for git, but it won't fix the builds for us.
> >
> >
> > No, but it would have prevented the problems in the first place,
> > because
> > people wouldn't commit their changes directly to 'trunk'.
> >
> > When several people make several changes to the same codebase, it
> > can be
> > hard to track down exactly which change caused an error.  In a project
> > like Phobos, where there is a lot of interdependence between
> > modules, it
> > may even happen that an error is caused by a combination of different
> > changes made by different people.
> >
> > And even when an error is tracked down, it may not be a trivial operation to remove the bad code again if there have been a lot of changes to trunk after the code was committed.
> >
> > I'm guessing this hasn't been a problem so far due to the relatively
> > low
> > number of Phobos developers.  But this seems to be changing now.
> >
> > Like Steve points out, it would be possible to use branches and
> > merging
> > when making changes.  There are some problems with this, though:
> >
> >     1. dsource's ancient SVN server is terribly bad at merging.
> >     2. The branches/ directory would quickly become an unwieldly mess
> >        if a new branch is created for every little change.
> >     3. SVN doesn't really seem to be designed with such a
> > decentralised
> >        coding model in mind.
> >
> > git, on the other hand, is made for exactly this purpose.
> >
> > With git, if I make a change to Phobos, I tell you guys: "Hey folks,
> > please pull this code from my repo and test it."  If there are no
> > problems with it, only then may it be included in the next release.
> > At
> > no point do I commit anything to trunk and say: "Hey folks, I've
> > *already* uploaded some not-completely-tested-nor-reviewed change to
> > our
> > single, common codebase.  It may break stuff for everyone in ways I
> > hadn't thought of, but hey, there's only one way to find out."
> >
> > Here are some more links for the curious:
> >
> >        http://en.wikipedia.org/wiki/
> > Distributed_revision_control_system
> >        http://en.wikipedia.org/wiki/Git_%28software%29
> >
> > -Lars
> >
> >
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

Yes, it does. :)

-Lars



On Wed, 2010-05-26 at 07:25 -0700, Sean Kelly wrote:
> We also need hardware. Does dsource support git?
> 
> Sent from my iPhone
> 
> On May 26, 2010, at 7:12 AM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> 
> > I'd say, if you (or anyone) want to switch to git, you must volunteer your time to be an administrator and go-to person for git. I can use git to find my way out of a paper bag, but not much more. We have a very strong git person at the company and I rely on him to fix any mess I'm doing. We need to garner some level of committment from a champion in order to switch to git.
> >
> > Andrei
> >
> > On 05/26/2010 04:19 AM, Lars Tandle Kyllingstad wrote:
> >> Was: Re: [phobos] phobos commit, revision 1553
> >>
> >>
> >> On Tue, 2010-05-25 at 09:32 -0500, Andrei Alexandrescu wrote:
> >>> I'd vote one up for git, but it won't fix the builds for us.
> >>
> >>
> >> No, but it would have prevented the problems in the first place,
> >> because
> >> people wouldn't commit their changes directly to 'trunk'.
> >>
> >> When several people make several changes to the same codebase, it
> >> can be
> >> hard to track down exactly which change caused an error.  In a
> >> project
> >> like Phobos, where there is a lot of interdependence between
> >> modules, it
> >> may even happen that an error is caused by a combination of different
> >> changes made by different people.
> >>
> >> And even when an error is tracked down, it may not be a trivial operation to remove the bad code again if there have been a lot of changes to trunk after the code was committed.
> >>
> >> I'm guessing this hasn't been a problem so far due to the
> >> relatively low
> >> number of Phobos developers.  But this seems to be changing now.
> >>
> >> Like Steve points out, it would be possible to use branches and
> >> merging
> >> when making changes.  There are some problems with this, though:
> >>
> >>      1. dsource's ancient SVN server is terribly bad at merging.
> >>      2. The branches/ directory would quickly become an unwieldly
> >> mess
> >>         if a new branch is created for every little change.
> >>      3. SVN doesn't really seem to be designed with such a
> >> decentralised
> >>         coding model in mind.
> >>
> >> git, on the other hand, is made for exactly this purpose.
> >>
> >> With git, if I make a change to Phobos, I tell you guys: "Hey folks,
> >> please pull this code from my repo and test it."  If there are no
> >> problems with it, only then may it be included in the next
> >> release.  At
> >> no point do I commit anything to trunk and say: "Hey folks, I've
> >> *already* uploaded some not-completely-tested-nor-reviewed change
> >> to our
> >> single, common codebase.  It may break stuff for everyone in ways I
> >> hadn't thought of, but hey, there's only one way to find out."
> >>
> >> Here are some more links for the curious:
> >>
> >>         http://en.wikipedia.org/wiki/Distributed_revision_control_system
> >>         http://en.wikipedia.org/wiki/Git_%28software%29
> >>
> >> -Lars
> >>
> >>
> >> _______________________________________________
> >> phobos mailing list
> >> phobos at puremagic.com
> >> http://lists.puremagic.com/mailman/listinfo/phobos
> > _______________________________________________
> > phobos mailing list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I don't believe that the recent issues had anything to do with order of submits, merges, or anything else that git would do differently than svn.  It had much more to do with 3 separate code bases that are interrelated: dmd, druntime, and phobos.

As much as I like git for some stuff, it's more complex to learn and svn is 'good enough'.  It's _far_ better than the nothing that existed before.

My 2 cents,
Brad

On 5/26/2010 2:19 AM, Lars Tandle Kyllingstad wrote:
> Was: Re: [phobos] phobos commit, revision 1553
> 
> 
> On Tue, 2010-05-25 at 09:32 -0500, Andrei Alexandrescu wrote:
>> I'd vote one up for git, but it won't fix the builds for us.
> 
> 
> No, but it would have prevented the problems in the first place, because people wouldn't commit their changes directly to 'trunk'.
> 
> When several people make several changes to the same codebase, it can be hard to track down exactly which change caused an error.  In a project like Phobos, where there is a lot of interdependence between modules, it may even happen that an error is caused by a combination of different changes made by different people.
> 
> And even when an error is tracked down, it may not be a trivial operation to remove the bad code again if there have been a lot of changes to trunk after the code was committed.
> 
> I'm guessing this hasn't been a problem so far due to the relatively low number of Phobos developers.  But this seems to be changing now.
> 
> Like Steve points out, it would be possible to use branches and merging when making changes.  There are some problems with this, though:
> 
>      1. dsource's ancient SVN server is terribly bad at merging.
>      2. The branches/ directory would quickly become an unwieldly mess
>         if a new branch is created for every little change.
>      3. SVN doesn't really seem to be designed with such a decentralised
>         coding model in mind.
> 
> git, on the other hand, is made for exactly this purpose.
> 
> With git, if I make a change to Phobos, I tell you guys: "Hey folks, please pull this code from my repo and test it."  If there are no problems with it, only then may it be included in the next release.  At no point do I commit anything to trunk and say: "Hey folks, I've *already* uploaded some not-completely-tested-nor-reviewed change to our single, common codebase.  It may break stuff for everyone in ways I hadn't thought of, but hey, there's only one way to find out."
> 
> Here are some more links for the curious:
> 
>         http://en.wikipedia.org/wiki/Distributed_revision_control_system
>         http://en.wikipedia.org/wiki/Git_%28software%29
> 
> -Lars
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos