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. > >> 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? 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.
> 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? > 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. > 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). > 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. > 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? > 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 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. Thanks, Justin
