Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of justinmclean@gmail.com
 designates 209.85.213.47 as permitted sender)
Sender: Justin Mclean <justinmclean@gmail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1280)
Subject: Re: The Git Branching Model: Will it work with SVN?
From: Justin Mclean <justin@classsoftware.com>
In-Reply-To: <CC49D179.443FB%aharui@adobe.com>
Date: Fri, 10 Aug 2012 14:15:13 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <14A6D947-B2DB-4648-8EAD-4D544A31892E@classsoftware.com>
References: <CC49D179.443FB%aharui@adobe.com>
To: flex-dev@incubator.apache.org

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.

>> 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?=20

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

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

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

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

Thanks,
Justin=