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.189 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 23:42:07 -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: Ac12u3hmFMHIV/nTTeGL84SGe6+kvgAB8oZD
Message-ID: <CC49FB4F.44418%aharui@adobe.com>
In-Reply-To: <99149CD6-0853-4BBF-869D-90320B71CDFB@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 10:45 PM, "Justin Mclean" <justin@classsoftware.com> wrote:

> Hi,
>=20
>> 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 histo=
ry?
> Using the command line for history is not really practical on code base t=
his
> large.
No, it is an option on the command=3Dline as well as described further down=
 in
the article I posted a couple of replies back.
>=20
>> No, I will continue to propose the tiered approach as I still think it i=
s
>> 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 convin=
ce 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.
>=20
>> 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 appl=
y 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 t=
hat
> 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 hav=
e
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.
>=20
>> 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.
>=20
> Thanks,
> Justin
>=20

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