Giovanni Bajo wrote:
> If you do a single merge that spans 20 revisions, there is basically no
> level at which Subversion knows which revision each line of change comes
> from, especially since the user is free of fixing conflicts (which might
> mean renaming couple things, moving things around across files and so on)
> before the commit.
Right now 'svn blame' works back from the latest revision requested until it
finds where a given line was last changed. It does this by comparing what lines
changed in each revision, which is the only information available from the
repository, as it stores only deltas (gross handwaving here, since there are
several types of deltas stored, which makes it easier to go back to a given
revision). This has nothing to do with the merge tracking; this is the only way
that blame can operate. There is no master list of what line changed where; it
must be recreated each time.
What I am suggesting is that the blame algorithm could be extended to ignore the
single rev at which a merge was done and follow the trail back to the original
source, using the merge-tracking information. There is no way of knowing where
and when a conflict was resolved, because the *only* information available out
of the repository is that this file was changed at rev X from this => to that.
This is completely analogous to the way that the copy-from information was used
to more fully replicate a file's history when running log (see --stop-on-copy).
> After the commit happened, a property simply pointing to
> the list of revisions from which the merge was done might be enough to
> reconstruct information for "svn log", but surely not for "svn blame" and
> maybe not even for "svn log -v". Even if you exclude the case of conflicts
> manually fixed by the user, only back-guessing (for the purpose of svn
> blame) the normal context heuristic done when a patch is applied looks
> pretty hard to me.
You are expecting way more than the Subversion repository can ever provide. The
only thing you can _know_ is that this file changed at that rev, and these are
the changes. At any revision, you *always* know what files changed (e.g. log
-v), and you always know what lines were changed in those files (the delta).
The only question is whether the merge-tracking information is sufficient to
look past it for blame purposes (and I think there is no reason to believe that
it won't be).
There is no way to /a priori/ know that a conflict was resolved (though you
could always rerun the merge) because there may be local changes that were not
reflected in the repository during the merge. This is unknowable information
under any circumstances (and a good argument for a site policy to always perform
merges directly within the repository, not using local copies).
I should say that I have been using SVK for the last several years to perform
these merge operations with very good results. Sometimes I merge into my WC (if
it is something that I want to test before committing) and sometimes I merge
from URL to URL (if I know the change is harmless or I intend to test after and
commit additional changes). Either way, if a conflict is found, SVK helpfully
offers to run my chosen merge editor to resolve the conflict and continue with
the commit.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 15 21:00:24 2006