You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Dave Fisher <da...@comcast.net> on 2012/08/13 23:38:29 UTC
[DISCUSS] Re: [VOTE] Branching Strategy and SCM
On Aug 13, 2012, at 1:43 PM, Omar Gonzalez wrote:
> On Mon, Aug 13, 2012 at 1:39 PM, Dave Fisher <da...@comcast.net> wrote:
>
>> My opinion/vote is (4) - no guts, no glory - work in trunk and learn to
>> co-operate.
>>
>> The vote is more about the Classic model than it is about Git vs. SVN.
>>
>> To me svn tag == git branch.
>>
>> Regards,
>> Dave
>
>
> People that use Git a lot would strongly disagree with "svn tag == git
> branch". For starters, SVN tags are supposed to not ever be edited, and Git
> branches are used for almost all new code addition/changes in the "nvie"
> model, so they're from from ==.
I'm more thinking this from what happens in the central repository and what gets marked up in the history from a few comparisons I've done.
When you branch in git you are marking where you are in the main repos, correct? If you never push it back the central repos never really cares about your branch, correct? So to the repository a branch is like a tag.
My opinion is that git is just putting off the work of integrating diverse changes into a single release. I feel the same about the 3-Tier plan. It is just putting ALL the work of deciding what is in a release to a Release Manager.
Really the Apache Way is for the Committers and the PPMC to share this responsibility. As this podling must know, you never, ever know when someone will exit.
But go ahead and go the way you want, it is up to you all.
Really what is the worst that can happen if someone plays in trunk and makes a mistake?
Regards,
Dave
>
> -omar
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Omar Gonzalez <om...@gmail.com>.
On Mon, Aug 13, 2012 at 2:38 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Aug 13, 2012, at 1:43 PM, Omar Gonzalez wrote:
>
> > On Mon, Aug 13, 2012 at 1:39 PM, Dave Fisher <da...@comcast.net>
> wrote:
> >
> >> My opinion/vote is (4) - no guts, no glory - work in trunk and learn to
> >> co-operate.
> >>
> >> The vote is more about the Classic model than it is about Git vs. SVN.
> >>
> >> To me svn tag == git branch.
> >>
> >> Regards,
> >> Dave
> >
> >
> > People that use Git a lot would strongly disagree with "svn tag == git
> > branch". For starters, SVN tags are supposed to not ever be edited, and
> Git
> > branches are used for almost all new code addition/changes in the "nvie"
> > model, so they're from from ==.
>
> I'm more thinking this from what happens in the central repository and
> what gets marked up in the history from a few comparisons I've done.
>
> When you branch in git you are marking where you are in the main repos,
> correct? If you never push it back the central repos never really cares
> about your branch, correct? So to the repository a branch is like a tag.
>
Branching and tagging are the same thing in SVN, the only real difference
is that it is understood that when you 'tag' something you are not meant to
check out the tag and make commits to it. The minute you commit to a tag it
become a branch. The distinction is not technical, its a convention.
>
> My opinion is that git is just putting off the work of integrating diverse
> changes into a single release. I feel the same about the 3-Tier plan. It is
> just putting ALL the work of deciding what is in a release to a Release
> Manager.
>
I don't know why you think its "putting it off", what its doing is
isolating work into branches that can be merged into a dev (next release)
branch when the time is appropriate (whenever that is, probably once the
branch has been discussed, fixed up, etc).
>
> Really the Apache Way is for the Committers and the PPMC to share this
> responsibility. As this podling must know, you never, ever know when
> someone will exit.
>
> But go ahead and go the way you want, it is up to you all.
>
> Really what is the worst that can happen if someone plays in trunk and
> makes a mistake?
>
Chaos that would affect all committers, which could be avoided by utilizing
branches and isolating work so that it is not disruptive to others work.
Being that we're all here on a volunteer basis I doubt anyone wants to
spend time cleaning up things that others broke because we are all in the
same trunk changing code and causing conflicts that could be avoided with
some clear workflows for the repository. Just because other projects are OK
with chaotic repos doesn't mean we have to be.
-omar
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Om <bi...@gmail.com>.
On Mon, Aug 13, 2012 at 3:29 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 8/13/12 3:24 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
>
> > 2012/8/14 Dave Fisher <da...@comcast.net>
> >
> >> One thing I like about SVN is that it discourages branching to necessary
> >> times while git encourages branching for a whim.
> >>
> >
> > SVN discourages branching because is not a core part in the design of the
> > system, while in Git is a core part.
> >
> > In SVN you try to not branch because you know the nightmare it could
> bring
> > to your source code. In Git you will want to branch because it brings
> > clarity and best practice to you development model...
> What is that "clarity"? Can you give me an example? If I want to
> contribute a set of Spark Charts, why should I have to cut a branch first?
> Why can't I just check in ChartBase into the "develop" branch, then add in
> Pie, Bar, etc over time in subsequent check ins as I finish them up?
>
There can be many scenarios. Let's say that while working on ChartBase you
realize that you can make it perform much better by tweaking something in
UIComponent. You cant make that tweak in 'develop' because everyone else's
work might get affected. So you cut a 'UIComponentTweak 'branch, make the
tweak to UIComponent, run regression tests for existing components and test
the new ChartBase. When you are happy, you merge the 'UIComponentTweak'
branch to 'develop' and continue working on 'develop'.
You may ask - why branch? Why not do all the work locally before checking
it into 'develop'. This prevents me from collaborating with others. I
might enlist the help of other committers and non-committers to help me run
regression tests if I do it on a branch on the remote repo instead of just
on my machine.
As you can see - you branch when you need to. No one is forced to not work
on the develop branch.
Om
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Carlos Rovira <ca...@codeoscopic.com>.
>
> OK, but even modifications can be done without branching, right? The key
> is
> not to check things into "develop" that breaks things.
>
> Other than Git handles branching better, the technical/logistical reasons
> for branching are the same in all SCMs, correct?
>
>
Alex, that's ok, and is up to you to take that kind of decission. It's like
to make to make a huge flex/java ERP with notepad. It can be done, but it
will very hard in the day-by-day basis. Better to choose directly the
better IDE to go as fast as possible.
Here's the same, you hardly will go the way to refactor UIComponent all
alone and not commit until work is done, because, you know, although that's
possible, it's highly improbable and you will need in some step to share
and test with other people, discuss code and so on.
One thing different in Apache from the work done in Adobe until this
release is that Flex 2.x, 3.x and 4.x was done internaly and only released
when the overall plan was complete. Now the playground is different and
people can share (commit in SVN) some unfinished work and then let the
trunk unstable until other people takes over this work to fix it.
This seems for me an horrible scenario and Git could avoid that because
PPMC will be pushing only stable features into develop from all pull
request ensuring "develop" and then "master" are always stable.
--
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: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Alex Harui <ah...@adobe.com>.
On 8/13/12 4:04 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
> Right! for that reason I said the new planed cases was something never came
> to flex before because all work was mainly "additive".
>
> If you plan to make a new component...you can make it in develop, because
> it will not break nothing! since is new and nobody is using it.
>
> Now thing in change UIComponent...it's clear that you can't make it in
> "develop" or you will generate a great problem once your first commit is
> done.
>
> Consider the following... if the road to Flex 5 will be 30% additive and
> 70% modification of core flex components...what will you choose? (i'm
> setting percents only as a staring point, do not read as if it was true).
>
OK, but even modifications can be done without branching, right? The key is
not to check things into "develop" that breaks things.
Other than Git handles branching better, the technical/logistical reasons
for branching are the same in all SCMs, correct?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Right! for that reason I said the new planed cases was something never came
to flex before because all work was mainly "additive".
If you plan to make a new component...you can make it in develop, because
it will not break nothing! since is new and nobody is using it.
Now thing in change UIComponent...it's clear that you can't make it in
"develop" or you will generate a great problem once your first commit is
done.
Consider the following... if the road to Flex 5 will be 30% additive and
70% modification of core flex components...what will you choose? (i'm
setting percents only as a staring point, do not read as if it was true).
Now if we are considering only add new components ad infinitum letting flex
as is, I will not loss any more time trying to argument why Git is the
option, and will not be worried for the SCM to choose, because it will not
be decisive in the long time.
Git ritght now is decisive in the short and in the long time...
IMO, if a new component is "working" (i.e. doesn't break any existing tests)
> and is ready for other folks to use, it should be allowed into the
> "develop"
> branch. It doesn't have to be feature complete, bug-free or otherwise
> production ready.
>
> For sure, if you are doing a risky change to UIComponent then a branch is
> wise.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
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: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Jeffry Houser <je...@dot-com-it.com>.
On 8/13/2012 8:23 PM, Om wrote:
> On Mon, Aug 13, 2012 at 4:48 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> SVN doesn't allow you to have more than one branch in your whiteboard?
>
> (This is probably tangential to the current discussion)
> As I understand, in the whiteboard, there is one single folder for each
> committer. What folder structure would you suggest for two features being
> worked on by a single committer?
whiteboard/committer/Feature1
whiteboard/committer/Feature2
I think plenty of committers already have something similar in their
whiteboard. I do.
such code [for me, at least] is not a branch/copy of the trunk,
though. But, there is no reason why it can't be in the future.
--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Alex Harui <ah...@adobe.com>.
On 8/13/12 5:23 PM, "Om" <bi...@gmail.com> wrote:
>
> Are you saying that we should go with SVN while at the same time adopting a
> branching strategy like the git branching model? I am not sure SVN can
> handle that.
>
> Om
Actually, I voted for #2 which is to use a simpler 3-tier model on SVN until
Git comes along and then move the 3-tier model to Git.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Om <bi...@gmail.com>.
On Mon, Aug 13, 2012 at 4:48 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 8/13/12 4:08 PM, "Om" <bi...@gmail.com> wrote:
>
>
> > A committer is free to decide what is unstable and what is complete.
> Fast
> > branching gives us the flexibility of sharing unstable features with
> > others, while keeping develop and master as stable as possible. The
> > current 'whiteboard' concept is not a real alternative because it forces
> > comitters to work on single features at one time. I will not be able to
> > experiment with core Mustella/FlexUnit/UIComponent and work on a new
> > component at the same time in my whiteboard. It causes me to needlessly
> > serialize my work.
> >
> > Om
> SVN doesn't allow you to have more than one branch in your whiteboard?
(This is probably tangential to the current discussion)
As I understand, in the whiteboard, there is one single folder for each
committer. What folder structure would you suggest for two features being
worked on by a single committer?
> Most
> of these arguments still seem to be about fear of merge-hell in SVN. Which
> is valid, but the logic about when to branch/merge seems to apply to both.
>
Branching is good - especially for a project like Flex, where concurrent
development needs to happen on various different parts of the codebase. We
should not stay away from branching just because SVN discourages it. At
the same time we should not go crazy creating branches just because Git
makes it easy to do it.
We must embrace any SCM that encourages branching and is efficient at doing
so.
Are you saying that we should go with SVN while at the same time adopting a
branching strategy like the git branching model? I am not sure SVN can
handle that.
Om
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Omar Gonzalez <om...@gmail.com>.
On Mon, Aug 13, 2012 at 5:19 PM, Gordon Smith <go...@adobe.com> wrote:
> How does Git make merges better than in SVN?
>
> - Gordon
>
>
In SVN when you make a branch you can essentially move it to any folder
when you choose a location. The /branches folder is the typical target by
convention, but you can place it anywhere in the repository and that's
where your branch goes.
In Git when you branch it is actually a project wide atomic snapshot, that
is, you don't choose a 'location' for your branch, the entire repository
contents are considered a different branch of the project. That is one
fundamental difference.
Git also has 'rebase', which lets you handle merging different than SVN
merging resulting in a much more linear and clearer history. Instead of
having "merge commits" where a bunch of code meets together and is merged a
rebase handles things differently. When you 'rebase' what happens is Git
knows what the 'parent' commit was and it unrolls all of your changes as if
you've just made the new branch, and then it puts them away in a 'stash'.
Git will then retrieve all of the new commits made to the originating
branch, after those are retrieved each commit is re-applied to your branch
in chronological order, allowing you to resolve conflicts as they happen as
if all commits on both branches were occurring one after the other. Because
of this you can handle updating old branches more efficiently and resulting
in a cleaner project repository history.
-omar
RE: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Gordon Smith <go...@adobe.com>.
How does Git make merges better than in SVN?
- Gordon
-----Original Message-----
From: Omar Gonzalez [mailto:omarg.developer@gmail.com]
Sent: Monday, August 13, 2012 5:12 PM
To: flex-dev@incubator.apache.org
Subject: Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
> SVN doesn't allow you to have more than one branch in your whiteboard?
> Most
> of these arguments still seem to be about fear of merge-hell in SVN.
> Which is valid, but the logic about when to branch/merge seems to apply to both.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
I would agree that the branching strategy can apply to both, its just a matter of which tool is going to handle these workflows better. Git will handle these workflows better because branching is its killer feature. In SVN branching is the feature that kills it, if you run into merge hell.
-omar
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Omar Gonzalez <om...@gmail.com>.
> SVN doesn't allow you to have more than one branch in your whiteboard?
> Most
> of these arguments still seem to be about fear of merge-hell in SVN. Which
> is valid, but the logic about when to branch/merge seems to apply to both.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
I would agree that the branching strategy can apply to both, its just a
matter of which tool is going to handle these workflows better. Git will
handle these workflows better because branching is its killer feature. In
SVN branching is the feature that kills it, if you run into merge hell.
-omar
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Alex Harui <ah...@adobe.com>.
On 8/13/12 4:08 PM, "Om" <bi...@gmail.com> wrote:
> A committer is free to decide what is unstable and what is complete. Fast
> branching gives us the flexibility of sharing unstable features with
> others, while keeping develop and master as stable as possible. The
> current 'whiteboard' concept is not a real alternative because it forces
> comitters to work on single features at one time. I will not be able to
> experiment with core Mustella/FlexUnit/UIComponent and work on a new
> component at the same time in my whiteboard. It causes me to needlessly
> serialize my work.
>
> Om
SVN doesn't allow you to have more than one branch in your whiteboard? Most
of these arguments still seem to be about fear of merge-hell in SVN. Which
is valid, but the logic about when to branch/merge seems to apply to both.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Om <bi...@gmail.com>.
> Normaly, if you are working in a set of spark charts, your work will spawn
> > over some weeks. So if you work directly on develop, you should not
> commit
> > your work to SVN until is done because you will make "develop" unstable
> > until you close the feature.
> Interesting, that's a different definition of "unstable" than I was
> thinking. One of the goals I think folks had was to get stuff out of their
> whiteboards and into a shared working environment sooner so more folks
> would
> notice it and it would get better faster. Requiring everyone to work in
> their own branches until "complete" seems overly restrictive.
>
>
A committer is free to decide what is unstable and what is complete. Fast
branching gives us the flexibility of sharing unstable features with
others, while keeping develop and master as stable as possible. The
current 'whiteboard' concept is not a real alternative because it forces
comitters to work on single features at one time. I will not be able to
experiment with core Mustella/FlexUnit/UIComponent and work on a new
component at the same time in my whiteboard. It causes me to needlessly
serialize my work.
Om
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Alex Harui <ah...@adobe.com>.
On 8/13/12 3:45 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
> Hi Alex,
>
> What is that "clarity"? Can you give me an example? If I want to
>> contribute a set of Spark Charts, why should I have to cut a branch first?
>> Why can't I just check in ChartBase into the "develop" branch, then add in
>> Pie, Bar, etc over time in subsequent check ins as I finish them up?
>>
>>
> First considere that in Git, "develop" use to be as stable as possible and
> you can make nightly builds from this branch and "master" use to be
> production ready with the release we made.
>
> Normaly, if you are working in a set of spark charts, your work will spawn
> over some weeks. So if you work directly on develop, you should not commit
> your work to SVN until is done because you will make "develop" unstable
> until you close the feature.
Interesting, that's a different definition of "unstable" than I was
thinking. One of the goals I think folks had was to get stuff out of their
whiteboards and into a shared working environment sooner so more folks would
notice it and it would get better faster. Requiring everyone to work in
their own branches until "complete" seems overly restrictive.
IMO, if a new component is "working" (i.e. doesn't break any existing tests)
and is ready for other folks to use, it should be allowed into the "develop"
branch. It doesn't have to be feature complete, bug-free or otherwise
production ready.
For sure, if you are doing a risky change to UIComponent then a branch is
wise.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi Alex,
What is that "clarity"? Can you give me an example? If I want to
> contribute a set of Spark Charts, why should I have to cut a branch first?
> Why can't I just check in ChartBase into the "develop" branch, then add in
> Pie, Bar, etc over time in subsequent check ins as I finish them up?
>
>
First considere that in Git, "develop" use to be as stable as possible and
you can make nightly builds from this branch and "master" use to be
production ready with the release we made.
Normaly, if you are working in a set of spark charts, your work will spawn
over some weeks. So if you work directly on develop, you should not commit
your work to SVN until is done because you will make "develop" unstable
until you close the feature.
In Git you will prefer to branch from "develop" and make a feature branch
called "spark-charts" that will allow you to commit to your local
repository (and if you want publish that branch in the remote) knowing that
you are not breaking nothing. When you finish your work, you can merge in
"develop" maintaining that branch stable.
Think now that other people are working in the refactor of UIComponent to
break into small components and behaviours. That task will be long in time
and will need to be finished before that people could merge it in
"develop". If not we will have flex broken for long time.
For this reason I say that IMHO we really does not have election. SVN is a
bad decission here, while GIT is the opossite...
If someone thinks that I'm wrong please let me know some arguments, because
maybe...I'm really wrong with my arguments! :)
--
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: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Alex Harui <ah...@adobe.com>.
On 8/13/12 3:24 PM, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
> 2012/8/14 Dave Fisher <da...@comcast.net>
>
>> One thing I like about SVN is that it discourages branching to necessary
>> times while git encourages branching for a whim.
>>
>
> SVN discourages branching because is not a core part in the design of the
> system, while in Git is a core part.
>
> In SVN you try to not branch because you know the nightmare it could bring
> to your source code. In Git you will want to branch because it brings
> clarity and best practice to you development model...
What is that "clarity"? Can you give me an example? If I want to
contribute a set of Spark Charts, why should I have to cut a branch first?
Why can't I just check in ChartBase into the "develop" branch, then add in
Pie, Bar, etc over time in subsequent check ins as I finish them up?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Carlos Rovira <ca...@codeoscopic.com>.
I propose we should try to continue discussion in the other thread and let
this only for voting, or it could grow too much and be complicated to
follow for people counting votes
--
> 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
>
>
--
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: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Carlos Rovira <ca...@codeoscopic.com>.
2012/8/14 Dave Fisher <da...@comcast.net>
> One thing I like about SVN is that it discourages branching to necessary
> times while git encourages branching for a whim.
>
SVN discourages branching because is not a core part in the design of the
system, while in Git is a core part.
In SVN you try to not branch because you know the nightmare it could bring
to your source code. In Git you will want to branch because it brings
clarity and best practice to you development model...
--
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: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Omar Gonzalez <om...@gmail.com>.
>
> > In the 3-Tier scheme how many buildbots and test rigs are required vs.
> the
> > work in trunk method?
> One CI server for trunk and one for "develop". In either scheme if you cut
> a branch I guess you have to add buildbots for them as well?
> >
>
>
Don't know why we would need more than one CI server, Jenkins can have
multiple jobs running at the same time, one server with multiple jobs
should be enough no?
-omar
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Omar Gonzalez <om...@gmail.com>.
One thing I like about SVN is that it discourages branching to necessary
> times while git encourages branching for a whim.
>
> These are my opinions, it is the project's choice.
>
> Regards,
> Dave
>
>
SVN discourages branching because branching inherently sucks in SVN.
Git encourage branching because branching is a lot better designed in Git.
There isn't a huge movement to Git and GitHub because developers like pain.
Developers are lazy people that want tools that make their lives easier,
not harder.
The proof is in the pudding, its not a coincidence that GitHub has gotten
so huge. Projects like the Linux kernel moved to Git for a reason, that
reason is SVN sucks.
-omar
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Alex Harui <ah...@adobe.com>.
On 8/13/12 3:15 PM, "Dave Fisher" <da...@comcast.net> wrote:
>
> On Aug 13, 2012, at 2:52 PM, Alex Harui wrote:
>
>>
>>
>>>
>>> Really what is the worst that can happen if someone plays in trunk and makes
>>> a
>>> mistake?
>>>
>>> Regards,
>>> Dave
>>>
>> For me, I don't like the psychology of reverting someone's changes, or even
>> my own. It feels like going backward. If the only public copy of some work
>> goes in trunk and then gets removed from the release branch, there is always
>> a chance that you'll mess up the re-integration. Yes, it is always in the
>> history to be fished out, but I'd rather avoid that.
>
> I am thinking about the psychology of working on a change and getting it all
> working in "unstable" and then waiting to see if the RM or PPMC or who exactly
> decides it is good enough to be in "stable" trunk. If I'm a committer then I
> should be trusted to not screw it up in the first place.
We had lots of good developers on Flex, but lots of stuff got checked in and
needed fixing later. In my mind, the community would have a discussion
about what goes in the release. Folks might say, "hey, feature X still has
a dozen open bugs" or, "I think feature Y is ready. I've been using it a
lot lately." I trust release managers to be eager to ship contributions but
be cautious enough to ensure high quality.
>
> If the project thinks it is near release then the group ought to work in not
> making unstable changes to trunk. We are all grown ups here aren't we?
I was under the impression that folks would be contributing all kinds of
stuff and at some point, someone would say "hey, let's release this stuff"
and start on the release process without too much advanced warning. Because
I have no idea what day we're going to decide to cut a release, I might have
just checked in new component like, say, a chart component that doesn't yet
handle labels for wedges that are too thin. That wouldn't be ready for
production, but ready for more adventurous folks to play with.
>
> In the 3-Tier scheme how many buildbots and test rigs are required vs. the
> work in trunk method?
One CI server for trunk and one for "develop". In either scheme if you cut
a branch I guess you have to add buildbots for them as well?
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Dave Fisher <da...@comcast.net>.
On Aug 13, 2012, at 2:52 PM, Alex Harui wrote:
>
>
>>
>> Really what is the worst that can happen if someone plays in trunk and makes a
>> mistake?
>>
>> Regards,
>> Dave
>>
> For me, I don't like the psychology of reverting someone's changes, or even
> my own. It feels like going backward. If the only public copy of some work
> goes in trunk and then gets removed from the release branch, there is always
> a chance that you'll mess up the re-integration. Yes, it is always in the
> history to be fished out, but I'd rather avoid that.
I am thinking about the psychology of working on a change and getting it all working in "unstable" and then waiting to see if the RM or PPMC or who exactly decides it is good enough to be in "stable" trunk. If I'm a committer then I should be trusted to not screw it up in the first place.
If the project thinks it is near release then the group ought to work in not making unstable changes to trunk. We are all grown ups here aren't we?
In the 3-Tier scheme how many buildbots and test rigs are required vs. the work in trunk method?
Sorry I've been a proponent of KISS for quite awhile.
One thing I like about SVN is that it discourages branching to necessary times while git encourages branching for a whim.
These are my opinions, it is the project's choice.
Regards,
Dave
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: [DISCUSS] Re: [VOTE] Branching Strategy and SCM
Posted by Alex Harui <ah...@adobe.com>.
>
> Really what is the worst that can happen if someone plays in trunk and makes a
> mistake?
>
> Regards,
> Dave
>
For me, I don't like the psychology of reverting someone's changes, or even
my own. It feels like going backward. If the only public copy of some work
goes in trunk and then gets removed from the release branch, there is always
a chance that you'll mess up the re-integration. Yes, it is always in the
history to be fished out, but I'd rather avoid that.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui