You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/08/16 09:24:35 UTC
Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote
Results)
As you may have seen, TLF is ready for donation. Falcon will be next week.
Given that, I think there are two "vectors" here that can be worked on in
parallel: 1) switching SVN usage to GBM and handling donations, and 2)
Getting a read/write Git repo.
It looks like there is a group of folks who are volunteering to work with
Infra so hopefully they will organize and make (2) happen.
Meanwhile, I think the rest of us can keep on using SVN. I don't think we
need to hold off for Git. I think the steps are:
(1) Rearrange SVN for new structure
(2) Create "develop" branch in sdk/trunk/branches
(3) Remove post-release commits from trunk and block the removal from
merging to "develop" branch.
(4) Start syncing and working from "develop" branch.
(5) Fixes to mustella go into "develop" and get synced to trunk
Thoughts?
-Alex
On 8/15/12 2:10 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
> On 8/15/12 2:04 PM, "Dave Fisher" <da...@comcast.net> wrote:
>
>>
>> If this is how the project wishes to roll then I would suggest the following
>> sequence assuming that Falcon is coming in a few days.
> The VP that signs these things won't sign until Monday at the earliest.
>
> FWIW, I think there will be at least one more donation (3.x) that was in
> Adobe SVN so keeping some sort of SVN around might be useful as a landing
> point then transferring to Git.
>
> I was thinking that it will be a few days until we get Git up and running
> even if we're very lucky so step 1.5 should be to create a develop branch in
> SVN and have folks get working (and branching) in SVN until Git is up.
>
>
>>
>> (1) Rearrange the SVN Repository for the new structure.
>>
>> (2) Import Falcon into SVN.
>>
>> (3) INFRA JIRA request for Git in the current supported mode. Include the
>> Flex
>> Git volunteers along with the PPMC, Committer, and/or Contributor status for
>> each.
>>
>> (4) Once the Git Mirrors are ready then let the pulls begin.
>>
>> (5) The Volunteers may help drive this to the desired, fully blessed, outcome
>> faster, or they might not, only work and time will tell. (Contributors may
>> very well earn enough merit for the PPMC to vote them Committer status.)
>>
>> BTW - There was an #asfinfra discussion about Apache Policy and enforcing no
>> log history rewrites along with requiring a rebase this morning. Didn't
>> follow
>> it too closely, but the result was the closing of an INFRA JIRA.
>>
>> Regards,
>> Dave
>>
>>
>>>
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Anyone interested porting this:
https://github.com/nvie/gitflow/
To use SVN?
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Aug 16, 2012 at 9:38 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> ...My guess (and hopefully I'm wrong but infra have a lot on their plate at the moment) that
> it will take some time to get GIt up and running for the project so it's likely we have
> to live with this for a while....
That's probable, http://s.apache.org/infra_git shows two projects
waiting since beginning of this month, and between INFRA-4137 and the
still experimental label of Git support, such requests are probably
handled with low priority.
-Bertrand
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Slightly off topic (no about Git) but may be of interest to people.
Mike Mason & Martin Fowler on feature branching
http://www.youtube.com/watch?v=xzstASOvqNc&feature=youtu.be
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
I'm with you Om. Now that we all have clear that we want 9# as a result of
the voting, it's a matter of getting the pieces enter in the puzzle. The
main thing here IMHO is that we choose for a model of future and we, as a
team, should row towards that goal.
2012/8/16 Om <bi...@gmail.com>
> On Thu, Aug 16, 2012 at 1:24 AM, Justin Mclean <justin@classsoftware.com
> >wrote:
>
> > Hi,
> >
> > I raised several concerns but lets not go over that ground again.
> >
> > We'll need to have some documentation on how it's going to work and what
> > SVN commands we need to use in each case. Anyone want to help out with
> this?
> >
> > We have a few people who don't know both SNV and Git well and no one used
> > Gitflow before (that I know) so even some simple guidance/instructions is
> > going to help everyone.
> >
> > >> How do we share the local branches that would exist in git?
> > > That may be one thing we can't do, but I don't think that was in the
> > > diagram, but I'm also not familiar enough with Git to say for sure.
> >
> > Most of the branches shown in the digram are local and only master and
> > develop are central in my understanding.
> >
> > Thanks,
> > Justin
>
>
> It is going to be a bit before we can answer all these questions. From the
> git branching model, we need master (trunk) and the develop branch right
> away. I believe everything else can wait and we can do it when needed.
> Any reason we need to branch right away? I am not aware of any major
> 'feature' branches or a release imminently coming up.
>
> Thanks,
> Om
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Justin
"So each new change would need to work in a feature branch and then merged
into develop? How/when is it decided to merge into develop? Can I do that
or do I need to involve other people? For "simple" changes do we just
commit straight in develop?"
I responded most of this in the response to Joao.
Regarding how to integrate GBM in SVN Pepe Barragan or I will post soon a
solution that could work.
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Please read the following article that is the the core of the development
> model selected:
> nvie.com/posts/a-successful-git-branching-model
I have but I'm unsure of exactly how to apply it in SVN. Hence my questions.
> the branch "develop" should be the place to work and the one of wich we
> could extract nightly builds because it should be stable over time (each
> feature merged with develop should be stable making develop stable as well).
So each new change would need to work in a feature branch and then merged into develop? How/when is it decided to merge into develop? Can I do that or do I need to involve other people? For "simple" changes do we just commit straight in develop?
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Yes, I mean "sharing" the local branch in the apache git, so everybody
could checkout and support the effort.
But take into account that it is not possible yet...
2012/8/16 João Fernandes <jo...@gmail.com>
> On 16 August 2012 12:45, Carlos Rovira <carlos.rovira@codeoscopic.com
> >wrote:
>
> > Hi Joao,
> >
> > as you say something so huge as UIComponent refactor should not be done
> in
> > "develop". Nothing that will take relative time should done in develop.
> > Only minor changes. "develop" always should be stable.
> >
> > The guy starting this effort should branch in a feature branch. For
> example
> > "uicomponent-refactor", and start working there. Only when the branch is
> > stable is when is merged back to develop.
> >
> > Since this feature is so huge and long term, normaly the guy starting the
> > effort based on some plan, should publish the branch so other people
> could
> > help him in such huge effort.
> >
> >
> By publishing do you mean creating that branch under the Apache git
> repository right?
> --
>
> João Fernandes
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Omar Gonzalez <om...@gmail.com>.
On Thursday, August 16, 2012, Justin Mclean wrote:
> Hi,
>
> > By publishing do you mean creating that branch under the Apache git
> > repository right?
>
> Currently (and likely to be the case for a few months) we would have to
> create a SVN branch which would be mirrored in the git mirror.
> https://github.com/apache/flex/branches
>
> Thanks,
> Justin
I can spend time today to work out the commands etc in SVN to pull off GBM.
I use GBM on my projects, and know SVN good enough to make the translation,
I also have a light day today.
-omar
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> By publishing do you mean creating that branch under the Apache git
> repository right?
Currently (and likely to be the case for a few months) we would have to create a SVN branch which would be mirrored in the git mirror.
https://github.com/apache/flex/branches
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by João Fernandes <jo...@gmail.com>.
On 16 August 2012 12:45, Carlos Rovira <ca...@codeoscopic.com>wrote:
> Hi Joao,
>
> as you say something so huge as UIComponent refactor should not be done in
> "develop". Nothing that will take relative time should done in develop.
> Only minor changes. "develop" always should be stable.
>
> The guy starting this effort should branch in a feature branch. For example
> "uicomponent-refactor", and start working there. Only when the branch is
> stable is when is merged back to develop.
>
> Since this feature is so huge and long term, normaly the guy starting the
> effort based on some plan, should publish the branch so other people could
> help him in such huge effort.
>
>
By publishing do you mean creating that branch under the Apache git
repository right?
--
João Fernandes
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Joao,
as you say something so huge as UIComponent refactor should not be done in
"develop". Nothing that will take relative time should done in develop.
Only minor changes. "develop" always should be stable.
The guy starting this effort should branch in a feature branch. For example
"uicomponent-refactor", and start working there. Only when the branch is
stable is when is merged back to develop.
Since this feature is so huge and long term, normaly the guy starting the
effort based on some plan, should publish the branch so other people could
help him in such huge effort.
2012/8/16 João Fernandes <jo...@gmail.com>
> I understand that we'll have a git repository clone from develop and master
> locally but for big changes that some are planning, shouldn't a dedicated
> branch be created (from develop) so pull requests could be made to that
> specific branch instead of develop?
> I'm asking this because I don't see a work like "UIComponent refactoring"
> being done directly under develop.
> Am I wrong?
>
> João Fernandes
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by João Fernandes <jo...@gmail.com>.
I understand that we'll have a git repository clone from develop and master
locally but for big changes that some are planning, shouldn't a dedicated
branch be created (from develop) so pull requests could be made to that
specific branch instead of develop?
I'm asking this because I don't see a work like "UIComponent refactoring"
being done directly under develop.
Am I wrong?
João Fernandes
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Justin,
So any changes I wanted to commit I'll need to commit to develop branch
> once it exists? How exactly is it decided that the branch should then be
> merged with trunk?
>
Please read the following article that is the the core of the development
model selected:
nvie.com/posts/a-successful-git-branching-model
the branch "develop" should be the place to work and the one of wich we
could extract nightly builds because it should be stable over time (each
feature merged with develop should be stable making develop stable as well).
"trunk" will become "master" and this should bring us the releases (passing
for a release branch to prepare the release).
So the main work should take place in develop and master should bring work
from develop when a release will scheduled (passing for a release branch
first)
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy
Vote Results)
Posted by Alex Harui <ah...@adobe.com>.
On 8/16/12 3:35 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> I would plan my changes so as not to break "develop" so I can just check it
>> in and share it even though it isn't 100% complete. If I can't do that I
>> would create a branch and folks can get at that branch from SVN if they want
>> to see what you are doing.
>
> The issue with is is that you need to know in advance if your changes will
> break the build in order to know to if you need to create a branch or not
> branch. I guess there are ways to do this ie work in develop, break it, create
> a patch, revert to develop, create new branch, reapply the patch and then
> commit new branch but probably needs to be documented.
>
> Thanks,
> Justin
>
I guess you could do that, usually I know whether I'm working on something
big that needs a branch or not. For normal bug fixes and small additions my
workflow would be to run mustella before checking in. That's why I'm trying
to get all mustella tests passing.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would plan my changes so as not to break "develop" so I can just check it
> in and share it even though it isn't 100% complete. If I can't do that I
> would create a branch and folks can get at that branch from SVN if they want
> to see what you are doing.
The issue with is is that you need to know in advance if your changes will break the build in order to know to if you need to create a branch or not branch. I guess there are ways to do this ie work in develop, break it, create a patch, revert to develop, create new branch, reapply the patch and then commit new branch but probably needs to be documented.
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy
Vote Results)
Posted by Alex Harui <ah...@adobe.com>.
On 8/16/12 1:54 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
>> It is going to be a bit before we can answer all these questions. From the
>> git branching model, we need master (trunk) and the develop branch right
>> away.
> So any changes I wanted to commit I'll need to commit to develop branch once
> it exists?
Yes, and Carol just created it so "svn switch" to it and continue on.
> How exactly is it decided that the branch should then be merged
> with trunk?
I expect there to be a discussion about cutting a release shortly, then when
folks agree, we'd cut a branch from "develop" to make a release branch,
finish the release there and merge to both trunk and develop.
> How do we keep the develop branch in a state in which that is easy
> to do. Do we need to create other branches for things that might need some
> more testing/may not be 100%?
Yes, create branches for stuff that will break the build. There will be
differing opinions on this, but I think it is ok to check anything into
develop that doesn't break the build. So, you don't really need to branch
to add a new locale, for example.
>
> For example let say I want to work on something like getting Mustella working
> with filenames with spaces. I check out the develop branch, then I get to a
> point were I almost have it working but not quite so I can't check it back
> into develop as it's not 100%. How do I then share that with other people can
> work on it/help me out? (With SVN not Git.) Do I need to create another SVN
> branch, merge my changes in develop with that and check that new branch back
> in as a feature branch or do something else? Or do we just do this on a case
> by case bases so it's not really the gitflow model but more like the 3 Tier
> SVN model?
I would plan my changes so as not to break "develop" so I can just check it
in and share it even though it isn't 100% complete. If I can't do that I
would create a branch and folks can get at that branch from SVN if they want
to see what you are doing.
>
> Thanks
> Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It is going to be a bit before we can answer all these questions. From the
> git branching model, we need master (trunk) and the develop branch right
> away.
So any changes I wanted to commit I'll need to commit to develop branch once it exists? How exactly is it decided that the branch should then be merged with trunk? How do we keep the develop branch in a state in which that is easy to do. Do we need to create other branches for things that might need some more testing/may not be 100%?
For example let say I want to work on something like getting Mustella working with filenames with spaces. I check out the develop branch, then I get to a point were I almost have it working but not quite so I can't check it back into develop as it's not 100%. How do I then share that with other people can work on it/help me out? (With SVN not Git.) Do I need to create another SVN branch, merge my changes in develop with that and check that new branch back in as a feature branch or do something else? Or do we just do this on a case by case bases so it's not really the gitflow model but more like the 3 Tier SVN model?
Thanks
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Om <bi...@gmail.com>.
On Thu, Aug 16, 2012 at 1:24 AM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> I raised several concerns but lets not go over that ground again.
>
> We'll need to have some documentation on how it's going to work and what
> SVN commands we need to use in each case. Anyone want to help out with this?
>
> We have a few people who don't know both SNV and Git well and no one used
> Gitflow before (that I know) so even some simple guidance/instructions is
> going to help everyone.
>
> >> How do we share the local branches that would exist in git?
> > That may be one thing we can't do, but I don't think that was in the
> > diagram, but I'm also not familiar enough with Git to say for sure.
>
> Most of the branches shown in the digram are local and only master and
> develop are central in my understanding.
>
> Thanks,
> Justin
It is going to be a bit before we can answer all these questions. From the
git branching model, we need master (trunk) and the develop branch right
away. I believe everything else can wait and we can do it when needed.
Any reason we need to branch right away? I am not aware of any major
'feature' branches or a release imminently coming up.
Thanks,
Om
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Using Git you have a complete repository localy in your machine.
Sure I understand that I do use git just not use gifflow before. We wont have full git support for a while. How do we work with SVN until then in the gitflow model? I know basically but the exact details I'm unsure on.
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Justin,
Using Git you have a complete repository localy in your machine. In
contrast with SVN there's only pointers not complete copy of files. For
this reason is a distributed repository. So all branches in remote could be
checkout in local and you can create local branches and be able to publish
in remote.
Regarding gitflow. If you are in Mac I recomend you to use the free client
SourceTree that brings GitFlow out of the box. GitFlow is very convenient
since is a group of scripts that modelize what we read in
nvie.com/posts/a-successful-git-branching-model
Since this is the development model selected would be great to use Gitflow,
but first we need to solve all the stuff that relate to get Git working...
> Most of the branches shown in the digram are local and only master and
> develop are central in my understanding.
>
> Thanks,
> Justin
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 35 57 77
<http://www.codeoscopic.com>
CODEOSCOPIC S.A. <http://www.codeoscopic.com>
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I raised several concerns but lets not go over that ground again.
We'll need to have some documentation on how it's going to work and what SVN commands we need to use in each case. Anyone want to help out with this?
We have a few people who don't know both SNV and Git well and no one used Gitflow before (that I know) so even some simple guidance/instructions is going to help everyone.
>> How do we share the local branches that would exist in git?
> That may be one thing we can't do, but I don't think that was in the
> diagram, but I'm also not familiar enough with Git to say for sure.
Most of the branches shown in the digram are local and only master and develop are central in my understanding.
Thanks,
Justin
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy
Vote Results)
Posted by Alex Harui <ah...@adobe.com>.
On 8/16/12 12:38 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> Well first concern is will the Git branching model actually work with SVN as
> described in the document? It wasn't designed with SVN in mind.
In the prior discussions, nobody came up with a reason the branches shown in
the article couldn't be done in SVN, but we should expect greater merge pain
when merging, and I would avoid major refactoring in the next release.
There was a post I read about git-svn that might be helpful. I will try to
find that tomorrow. It talked about what kind of Git branching can mess up
git-svn. We should try to avoid that for now.
>
> So what changes need to be made to the process it in order for us with work
> cleanly with SVN?
I think we have to be careful about making lots of branches, but I think SVN
can handle the branching in the diagram.
> For instance how is history going to be managed when
> merging?
History will be handled however SVN handles merging and history.
> How do we share the local branches that would exist in git?
That may be one thing we can't do, but I don't think that was in the
diagram, but I'm also not familiar enough with Git to say for sure.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Getting To Git (was Re: [MENTORS] Current Branching Strategy Vote Results)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Well first concern is will the Git branching model actually work with SVN as described in the document? It wasn't designed with SVN in mind.
So what changes need to be made to the process it in order for us with work cleanly with SVN? For instance how is history going to be managed when merging? How do we share the local branches that would exist in git?
My guess (and hopefully I'm wrong but infra have a lot on their plate at the moment) that it will take some time to get GIt up and running for the project so it's likely we have to live with this for a while.
Thanks,
Justin