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 05:20:40 GMT

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

> Hi,
>> Well, there might be a better way, but by your reasoning we would never
>> branch.
> No I am against have a single unstable branch. I see far less issues if we did
> use multiple branches (ie one branch per change) OR most small changes in
> trunk and branch when needed as suggested by the SVN best practice document.
I am specifically asking about the Git Branching Model in this thread, which
I don't believe conforms to either of patterns you like.  However, I did
find the better way.  You can request the log to include merge-info and it
will.  SmartSVN shows it as child nodes of the merged log entry.
>>> We not talking about the git branching model we are talking about using a
>>> single unstable branch or so I thought?
>> Not in this thread, see subject.
> OK so just to confirm you now think that a singe unstable branch is not the
> way to go?
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.
>> Maybe you can provide an example?  I don't see how one way pushes from
>> unstable/develop can cause a conflict in trunk.
> Because of existing changes that have not been pushed into trunk. Person A
> checks in files A,B and C (in one changeset), Person B modifies and checks in
> file B, Person A then modifies and checks in file B again all in a non trunk
> branch. Merging persons A changeset with trunk could then likely to cause an
> issue and the trunk may not be in a usage state. To fix that you then have to
> make changes directly to trunk and then you would need to sync those changes
> with the branch. The simple way around this issue is to always merge entire
> branches.
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.

> I also read carefully the "More on Merge Conflicts" section in the link you
> provide. Yes you can cherrypick and block changesets (and shown in the link
> you provided) but it's seem overly complex to need to do that all the time
> rather than is just exceptional circumstances.
I disagree that this will happen "all the time".  But we'll find out because
I expect either the tiered model will win again or the Git Branching Model
will win and we will be doing merges.
>> In the Git Branching Model, when we decide we want to prepare a release
>> (which would not be daily) we would cut a release branch from develop and
>> either take a bunch of known good commits or take from the head, remove and
>> block.
> In which I think you run into the same issues as above re using a single
> branch and selecting changesets.
And again, I don't see how that would cause a merge conflict.
>> In the Git Branching Model, you would do the merge, resolve conflicts and
>> block manually resolved conflicts.
> Which doesn't answer my question of how you would keep develop/unstable in
> sync with the trunk. (See above).
In the Git Branching Model, the trunk only receives merges from release
branches.  The release branch gets synced with trunk and develop.  All
changes to trunk that should be in develop should be in at that time.  It
must be working satisfactorily otherwise it wouldn't have fans.

>> I think the trunk history may not be any different if we use the Git
>> Branching Model entirely in SVN because the only commit to trunk is from a
>> release branch merge operation.
> Can you think of any way to keep the revision history? It's sometime very
> useful to know what small changes were made when, rather than knowing a whole
> lot of files and lines changed in this release.
It appears that by asking for merge-info in the logs you can see all the
changes that went into a merge.
> Thanks,
> Justin

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message