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