On 8/9/12 5:50 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
> HI,
>
>> So, while the poll is leaning towards an unstable branch, there seems to be
>> a lot of interest in the Git Branching Model described here [1].
> And there's also more interest in multiple branches than a having a single
> unstable branch and also using trunk as the main working area and having a
> branch for each release.
>
> Before we decide on using a single unstable branch I would like someone to
> confirm the exact sequence of SVN commands needed to work with SVN like this.
>
> In particular I think these questions need to be answered:
> 1. How do we preserve history of changes (and check in comments) in the
> unstable branch when merging with trunk. I'm not 100% if this is an issue or
> not.
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.
> 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 because
there shouldn't be any independent changes to trunk/master. But for us, we
occasionally had to hand merge something. If you ever cut a branch, you
risk having to deal with a conflict by hand-merging.
> 3. How do we keep the unstable branch in sync with the trunk (esp when changes
> need to be made in trunk due to conflicts).
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 and
won't be attempted on the next merge. I never had to do that, our build
engineer did it, but I'm guessing that's the option he used based on the SVN
doc.
>
> I did a rough outline of steps here:
> http://markmail.org/message/o4unlhvlfqjprhj7
I didn't like the way your list was set up. Some steps you only do once and
some you do often.
For example, you will do one extra checkout ever (of the unstable branch).
Your daily workflow should be no different than working in trunk.
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, and
commit. But this may not be daily or per change. We might batch these up
and have the release manager do them.
In the Git Branching Model, I think we would cut a release branch from the
last known good tag of the last release, then select certain revisions to be
merged into that branch. I'm not sure it would be right to cut release from
the head of "develop" in our case because new stuff in "develop" will be in
various stages of "done-ness" and don't have to ship in a particular
release, and I'm worried about blowing it when merging back to from
"release" to "develop" if we remove stuff from the release branch that isn't
"done".
In my tiered-branch proposal, instead of cutting a release branch, we would
simply promote certain revisions to trunk and polish the release in trunk,
but it is otherwise the same steps and risks.
>
>> I am thinking of running a new poll that includes this model, but I want to
>> make sure that there isn't going to be an obvious show-stopper with SVN if
>> it wins.
> Git is much better at handling branches so I would expect there to be some
> issues but IMO there would be less issues than if we used a single unstable
> branch.
>
>> I also pondered the notion of a variant where SVN trunk is the "master" and
>> we use a Git branch as the "develop" branch.
> You can do this via git-svn
> (http://www.kernel.org/pub/software/scm/git/docs/git-svn.html) but that adds
> further complications. As git is decentralised (ie you work in local copy and
> there is no master) how do you expect the develop branch to be shared? hosted
> on github perhaps?
I thought there was already a Git mirror of Apache Flex SVN? Or that we can
get one? And that would be "develop"? Again, I haven't paid any attention
to the Git side of things.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
