On Thu, Aug 9, 2012 at 10:45 PM, Justin Mclean <jus...@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
