incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: The Git Branching Model: Will it work with SVN?
Date Fri, 10 Aug 2012 06:42:07 GMT



On 8/9/12 10:45 PM, "Justin Mclean" <justin@classsoftware.com> wrote:

> Hi,
> 
>> You can request the log to include merge-info and it
>> will.  SmartSVN shows it as child nodes of the merged log entry.
> So we need to use a commercial plug in in order to see the full log history?
> Using the command line for history is not really practical on code base this
> large.
No, it is an option on the command=line as well as described further down in
the article I posted a couple of replies back.
> 
>> No, I will continue to propose the tiered approach as I still think it is
>> simpler, but I will give folks a third option of the Git Branching Model.
> OK so it seems we still have no consensus until we do (and you can convince me
> otherwise) do I'll continue to work in trunk.
If I understood Bertrand, the results of the poll will be binding, so you
have to work within whichever plan wins.
> 
>> I am not an expert, but I do not believe your scenario can cause a merge in
>> the Git Branching Model or the tiered model because the changes you apply to
>> the destination will not have already changed in the destination.
> You will end up with a trunk that could be broken and an another branch that
> is out of sync because it is missing changes made in trunk.
I hope the develop branch will hardly every match trunk completely because
it will be containing changes not yet ready for primetime because we'll have
lots of active committers.  My understanding of the Git Branching model is
that trunk is essentially a mirror of a non-broken release branch so I don't
see trunk being broken under that plan.
> 
>> And again, I don't see how that would cause a merge conflict.
> Because you have cherrypicked changes/only committed some changesets and not
> merged the entire branch. As you merge one persons changelists one by one you
> can get a conflict due to unapplied changesets from other people.
I am not an expert, but my undertanding is that cherrypicking doesn't cause
merge conflicts although it could result in something being broken if you
miss an important revision. But that should be found in testing of the
release branch before it gets merged to trunk.
> 
> Thanks,
> Justin
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui


Mime
View raw message