On 8/9/12 8:26 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
> Hi,
>
>> 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.
>>
>>> 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.
> 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 from
> 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 trunk.
Maybe you can provide an example? I don't see how one way pushes from
unstable/develop can cause a conflict in trunk.
>
>> 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.
> OK so something else everyone needs to know when committing code from unstable
> to trunk. I was unaware of that SVN option. This will have to be very
> carefully documented.
>
>> 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.
> 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 needs 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 manager
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.
>
>> 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.
>
>> Your daily workflow should be no different than working in trunk.
> It is different because you have to merge when moving changesets one by one
> 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.
>
>> 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.
> 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.
>
>> 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 who
> 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.
>
>> I thought there was already a Git mirror of Apache Flex SVN?
> Yep we could use that.
>
>> 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.
>
> Thanks,
> Justin
>
[2] http://www.visualsvn.com/support/svnbook/branchmerge/advanced/
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
