Giovanni Bajo wrote:
> Daniel Berlin wrote:
>
>> So, the real problem here is that merges are not considered a seperate
>> operation, they are just a bunch of adds, deletes, and changes applied
>> to a versioned tree. We don't know it's a merge if we look at
>> history.
>
> Roger that. Would it be possible to change this in future, or would it be
> too large a change for SVN and its architecture?
>
Anything can change. If you want to seriously propose it and work on it,
go for it. However, it's certainly not necessary to get good
history-sensitive blame, it's only necessarily to make it faster :)
:)
>> This is not necessary with the mergeinfo scheme, nor would it help.
>> It is just as good/bad as querying for a list of when mergeinfo has
>> changed for a given path, and saying any time forward mergeinfo
>> changed, the operation was a merge, not a real change, and exclude
>> that author from blame results (or something similar).
>
> The problem is that you can't simply exclude the author: you'd want to see
> the original authors of the merged changes to appear instead.
Yes, i'm aware.
>
> - Merge the py3k-branch into trunk, and (in a way) lose *whole* py3k
> history.
Only insofar as you mean "who wrote the original code" to mean "history" :)
Since py3k is expected to contain pretty substantial change, svn
> log / blame will be totally useless,
blame maybe, but not log, since log would tell you who made the original
change.
Blame is already "wrong" portions of the time anyway, just because of
the way it works.
and people will have to keep falling
> back to logging/blaming the py3k-branch (and don't even mention what the
> command line syntax would look like if they svn rm'd the py3k-branch after
> the merge...).
>
> - Close the trunk and rename the py3k-branch to trunk. This will keep the
> py3k history, but will lose the history of Python 2.x features, bugfixes,
> etc, since they would appear as big merges from the trunk happened in the
> branch. Also, developers will have large headaches trying to find out the
> magical command-line combination of -r, -c, and pegrevs to log/blame the
> "old" trunk before it was closed :)
>
> So, do you confirm that the ongoing work on merge-tracking will not improve
> this problem in any way?
So, uh, again, it will improve it in the way i've said before. It would
enable history-sensitive blame to work.
It will enable you to figure out where you'd need to look to determine
whether a change is really new, or just copied code.
This was not available before, because you didn't know where the merge
came from.
You can get fine history-sensitive blame this way.
This is a much more complicated algorithm than i described above, but a
simplified version is:
For each rev of the file you are blaming, in reverse (ie highest to
lowest revnum):
If the mergeinfo changed between this rev and the last
fetch the rev the current rev was merged from
determine what changes were not in the original merged-from rev, but
are in the current rev
Blame these with the current author
For all other parts of the file, determine which branch of the new
mergeinfo for this rev it came from (brute force, whatever).
Recurively blame this "chunk" as if we were blaming the rev/path it
came from.
Else
Blame normally
This will even handle when multiple portions of the file came from
multiple branches.
Do you believe that this kind of problem is a no-go
> with SVN now and ever, given its architecture, or do you foresee future ways
> to have this solved?
I think you can do history/merge sensitive blame without any
architecture changes, it just may be slower than you like.
It would certainly be a lot *easier* and *faster* if we knew which were
merges, and which were not. But it's not impossible, given the mergeinfo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 15 16:49:42 2006