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?
> You will never perfectly be able to tell, even if you were to add a
> property, because someone could always tweak the property post-hoc.
... not that I care about people lying to themselves.
>> If you keep merge-tracking history in revprop, so that r100 has a
>> revprop saying "I'm a merge of r10-20" (which is what you are doing,
>> IIRC), would it be possible to tweak svn log/svn blame so that they
>> follow these "merge links" and display information based on the
>> original revisions?
>
> 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.
Let me give you a concrete scenario. Python developers created the
py3k-branch to work on the famous Python 3000 version. On trunk, development
is going on Python 2.x, and they are regularly merging from the trunk to
py3k-branch (using svnmerge.py right now). Now, one day in the future, when
the py3k work will be done (let's say it takes 2 years), they have two
possibility:
- Merge the py3k-branch into trunk, and (in a way) lose *whole* py3k
history. Since py3k is expected to contain pretty substantial change, svn
log / blame will be totally useless, 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? 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?
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 15 11:35:06 2006