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 omarg.developer@gmail.com
 designates 209.85.220.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <99149CD6-0853-4BBF-869D-90320B71CDFB@classsoftware.com>
References: <CC49E838.4440A%aharui@adobe.com>
	<99149CD6-0853-4BBF-869D-90320B71CDFB@classsoftware.com>
Date: Thu, 9 Aug 2012 22:51:18 -0700
Message-ID: 
 <CAEFz_vu+SvEXoXhX6kqBbHkk2c=rKZ1Jz7JfQ1cQqR1CxVnK9Q@mail.gmail.com>
Subject: Re: The Git Branching Model: Will it work with SVN?
From: Omar Gonzalez <omarg.developer@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae9ccd510d7a96104c6e2eeaa

--14dae9ccd510d7a96104c6e2eeaa
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 9, 2012 at 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.
>

I don't think Alex is saying you have to use a commercial plug in, just
pointing out how SmartSVN's GUI shows it. SmartSVN is not a plug in either,
its an SVN client.


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


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

If we could just switch to Git we wouldn't have any of these stupid
problems with merging to begin with.


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

Again, problems that don't happen in Git because of the fundamental ways in
which in handles merging and revisions.

Yes, I'm trying to push the conversation in the direction of switching the
entire SCM solution. It would be best for the project to step out of the
dark ages of SCM and into the new age.... ;-)

-omar

--14dae9ccd510d7a96104c6e2eeaa--