On Aug 10, 2012, at 10:22 AM, Gordon Smith wrote: > After Falcon is donated I expect to be making lot of changes to complete its > MXML support. I strongly prefer to be able to work in SVN and not to have to > learn Yet Another Source Code Control System. Is the idea that SVN would stay > the primary repository and Git might become any option for development > branches?
That seems to be what is written on http://www.apache.org/dev/git.html As suggested the status may have progressed. To check you can search the infrastructure-dev archives, or you can ask on IRC #asfinfra (I feel exactly like you about git, but am about to be pulled into its world because that's how some people I work with roll.) Regards, Dave > > - Gordon > > -----Original Message----- > From: Carol Frampton [mailto:[email protected]] > Sent: Friday, August 10, 2012 7:31 AM > To: [email protected] > Subject: Re: What would it take to move to Git? > > > > On 8/10/12 5 :00AM, "Carlos Rovira" <[email protected]> wrote: > >> We must take into account that low activity was due to donation and >> create a first incubation SDK. In the next months more people should >> come to the project as it helps to develop some patch, bug or modification. >> >> The infrastructure should support huge changes and must be set up >> before those changes start to be developed. Changes to UIComponent, >> HTML5 port, and so on are huge and must live with the actual evolution >> of other minor things. >> >> So taking into account that there are aggresive modification plans in >> mind, I think we should go with the best branching model and not the >> simplest. >> If >> there was no plans, maybe the later will be best. >> >> >>> Agreed, but considering the relatively low commit activity ATM (I'm >> listed 7th at [1] with 32 commits since January, which have nothing to >> do with Flex code for example)., I'm wondering if it would make more >> sense to start with the *simplest* branching model as opposed to the >> *best* one, for now. You might need the latter downstream, but probably >> not right now. > > > Personally I'd like to come up with a relatively simple scheme for branching > using SVN and then get to work, especially since Apache infra still considers > Git experimental. I'm guessing we are one of the larger projects at Apache > in terms of code size and I want us to be able to get infra support. I know > we've used their services quite a few times already. > > We've spent 8 months pushing existing code around and not making any forward > progress with Flex. I understand that some people prefer Git but at this > point everyone knows SVN to some level and not everyone knows Git. > > Assuming we will release from trunk, I don't think everyone working in trunk > can work, even aside from the stability issues. If we all worked for the > same company, and all signed up to get our features done by date X so we > could release on date Y it might be possible. In the Apache model people > work on things when they can, so there might be features/components that > aren't done when someone decides to do a release. > > I think Alex is proposing that we all work in the dev branch (aka > unstable) and when it is time to release we cherry pick changes to move back > to trunk and then release from trunk. We would not be merging on a daily or > even weekly basis but at release time (perhaps too corporate but could also > have base levels and merge then). I think Justin raises some legitimate > concerns about multiple changes being made to the same file but I think we > can come up with a solution for that. Perhaps changes don't get even get > committed to the dev branch until you think they are worthy of release but > there are other alternatives as well. > > I think you could also flip this and do dev work in trunk and then create a > branch for the release that was based on the last release tag and then you > move changes from trunk over to the release branch. > > I'm having a hard time following the Alex/Justin discussion but I have read > some misinformation about SVN in there. You can do an svn merge and then if > there are conflicts, go back and resolve those conflicts and mark the files > resolved with svn resolve. Then you svn commit the results of the merge. > You can also block merges with svn --record-only merge. > > Carol >
