incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Smith <gosm...@adobe.com>
Subject RE: What would it take to move to Git?
Date Fri, 10 Aug 2012 17:22:01 GMT
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?

- Gordon

-----Original Message-----
From: Carol Frampton [mailto:cframpto@adobe.com] 
Sent: Friday, August 10, 2012 7:31 AM
To: flex-dev@incubator.apache.org
Subject: Re: What would it take to move to Git?



On 8/10/12 5 :00AM, "Carlos Rovira" <carlos.rovira@codeoscopic.com> 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


Mime
View raw message