On Tue, Jul 12, 2011 at 1:05 PM, Andy Singleton <a...@assembla.com> wrote: > Log and blame will not be problems. My proposal does not change log or > blame. They will still work fine if you apply newmerge. The revisions and > authors and commit messages are still in the repository in the same place, > and log and blame will still show them.
I am specifically talking about the -g options. I should be able to run blame -g and see the revision and author that changed the line of code, not the revision and author that merged the changes to the current branch. Likewise, when I run log, I want the revisions that are merges to be able to show me the details of the revisions that were merged. Users have been clear that these are essential features of merge. Likewise, the existing mergeinfo command (which could be improved) is necessary. It lets someone ask what has been merged to this branch or what is eligible to merge to my branch. I know there are some people that use the command line, but the GUI tools like Subclipse, AnkhSVN and TortoiseSVN use the underlying API to drive their merge-friendly GUI tools. I am only pointing these out so that you plan for them in your design. > There are only two cases that seem relevant to the newmerge proposal: > * If you do a move, you lose history prior to the move. This is not new. Huh? I am not aware of this. This is the only feature that SVN actually supports. It does NOT lose history. When SVN 1.0 bragged about its merge support it was because of this feature. The problem with move is that we do not have any real record of where something was moved to, only where it was moved from. So do not have a good way to show moves and of course we do not automatically handle them in update and merge. > * If you have foreign merges, you can lose some detail about individual > commits that were done in the foreign repository. Instead, you might get > information about the merge commit that included them. This is graceful > degradation, and it's less than people are already tolerating with moves. Yes, and fwiw, I am fine with the limitations in this case. Improving this in the long term would be cool, but I do not personally care if we make any improvements in this area in the near term. -- Thanks Mark Phippard http://markphip.blogspot.com/
