On Tue, Jul 12, 2011 at 1:05 PM, Andy Singleton <andy_at_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/
Received on 2011-07-12 19:33:14 CEST