flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: What would it take to move to Git?
Date Fri, 10 Aug 2012 18:00:20 GMT

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.)


> - 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

View raw message