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 aharui@adobe.com designates
 64.18.1.25 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Thu, 9 Aug 2012 20:43:37 -0700
Subject: Re: The Git Branching Model: Will it work with SVN?
Thread-Topic: The Git Branching Model: Will it work with SVN?
Thread-Index: Ac12qAiPQD67pWdVS+WD8met1KxoCQAAkpLU
Message-ID: <CC49D179.443FB%aharui@adobe.com>
In-Reply-To: <2597ACA0-7D34-437A-9311-8A7EEA08D7C0@classsoftware.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


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

> Hi,
>=20
>> For us, the trunk log said things like "Merge revs 100-150 from Unstable=
"
>> and you would go to the Unstable working copy and view the logs there.
> I think that's a significant technical negative to not use this approach.
Well, there might be a better way, but by your reasoning we would never
branch.

>>=20
>>> 2. How do we deal with conflicts in trunk when merging changesets from =
the
>>> unstable branch.
>> This should in theory be extremely rare in the Git branching model becau=
se
>> there shouldn't be any independent changes to trunk/master.
> 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.
> IMO conflicts will be reasonable
> common as you need to check in multiple changesets from a single person f=
rom
> unstable to trunk when other people have made changes in unstable as well=
. If
> we were checking all of unstable into trunk there would be less issue but=
 you
> can't do that as some people's changes may not be ready to check into tru=
nk.
Maybe you can provide an example?  I don't see how one way pushes from
unstable/develop can cause a conflict in trunk.
>=20
>> After resolving a conflict by hand-merging, I think you use the -record-=
only
>> option to mark the conflicting revisions so they are considered merged a=
nd
>> won't be attempted on the next merge.
> OK so something else everyone needs to know when committing code from uns=
table
> to trunk. I was unaware of that SVN option. This will have to be very
> carefully documented.
>=20
>>  I never had to do that, our build engineer did it, but I'm guessing tha=
t's
>> the option he used based on the SVN
>> doc.
> And we don't have a build engineer for Apache Flex. Any chance you could =
ask
> them to either document the process or provide any existing documentation=
?
The build engineer is gone.  I think we're smart enough to figure out it.
See [2].  It seemed useful.

>> I didn't like the way your list was set up.  Some steps you only do once=
 and
>> some you do often.
> Fine can you please come up with a list step by step that shows what need=
s to
> be done so that it's clearly understood by all committers.
You clipped it out.  It was in my previous reply.  You do your work in
unstable/develop as normal.  In the Git Branching Model, the release manage=
r
will merge specific revisions or ask you to do so when it is time, or maybe
branch from develop's head, remove some and block the removals.
>=20
>> and/or check inFor example, you will do one extra checkout ever (of the
>> unstable branch).
> But you do need two full copies right? As opposed to working in trunk (or
> using multiple short lived branches).
Yes, two copies in the tiered proposal and in the Git Branching Model.
>=20
>> Your daily workflow should be no different than working in trunk.
> It is different because you have to merge when moving changesets one by o=
ne
> from unstable to trunk rather than just checking in.
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.
>=20
>> Then when we want to merge back to trunk, you have one extra SVN update
>> since there is an extra branch, the merge, conflict resolution if any, a=
nd
>> commit.
> And after the final commit to trunk how do you then make unstable in sync=
 with
> trunk if you needed to resolve any conflicts in trunk?
In the Git Branching Model, you would do the merge, resolve conflicts and
block manually resolved conflicts.
>=20
>>  But this may not be daily or per change.  We might batch these up
>> and have the release manager do them.
> IMO that places a rather large burden on the release manager and limits w=
ho
> can be the release manager to people who are SVN experts.
I think any person currently in the PPMC is intelligent enough to be a
release manager.
>=20
>> I thought there was already a Git mirror of Apache Flex SVN?
> Yep we could use that.
>=20
>> Or that we can get one?  And that would be "develop"?
> No it would be both the trunk and unstable. You would merge everything in=
 git
> trunk and them commit changes back to the SVN trunk. We would also miss a=
 lot
> of SVN history if we went down this path.
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.
>=20
> Thanks,
> Justin
>=20
[2] http://www.visualsvn.com/support/svnbook/branchmerge/advanced/
--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui