Danil Shopyrin wrote:
>>> 2) Mergeinfo produced during WC-to-WC copy differs from equivalent
>>> REPO-to-REPO copy. If you copy file in working copy and there is no
>>> mergeinfo in the working copy then the new file will get an empty
>>> mergeinfo record. Similar REPO-to-REPO copy operation doesn't produce
>>> empty mergeinfo record.
>>>
>>> This problem was already discussed here:
>>> http://svn.haxx.se/users/archive-2008-08/0471.shtml
>> That's correct. A WC-to-WC copy isn't allowed to speak to the repository,
>> so it doesn't have the opportunity to verify that "no mergeinfo" is the
>> correct result. To be safe, it sets empty mergeinfo (to block any
>> inheritence it couldn't have foreseen due to lack of repository access). As
>> you note below, though, there are some cases when we can be smarter about this.
>
> Can appropriate checks be done at commit stage? The logic can be as
> follows: if we have "added and copied" paths then we should compute
> appropriate mergeinfo for them. As I understand, there is no problems
> with connection to the repository at commit stage.
We toyed with this, but the problem (or one of the problems) we ran into was
what happened if you performed a copy (perhaps to make a local branch), then
tried to merge into it. The merge needs that mergeinfo as much as commit
might. And maybe the answer there that 'merge' also grows the ability to
detect stale-and-in-need-of-network-refreshing mergeinfo on working copy
members, and does said refreshing before performing its primary task. I dunno.
> I can provide a 'very dirty prototype patch' if this solution is acceptable.
That's fine. Just understand that while very dirty prototype patches are
interesting, but nice clean ready-for-commit patches get more attention. :-)
>>> 3) Unnecessary mergeinfo records are produced on copy operations. If
>>> user plainly renames file1.txt to file2.txt in the same folder then
>>> file2.txt gets explicit merge even if file1.txt didn't have one. In
>>> agile environments file renaming is performed very often and this
>>> result in whole working copy filled by unnecessary mergeinfo records.
>>> This slows down merge operation dramatically.
>> We agree. I thought there was an issue for this already, but I can't find
>> it. In general, the behavior should be: Figure out what the mergeinfo for
>> the target would be, and if it's no different than the mergeinfo for the
>> source location, don't set/change it.
>
> I also found that these unnecessary mergeinfo records also break
> 'svn merge --reintegrate' command. Empty mergeinfo records break
> --reintegrate option too. This is also described by Mark Phippard at
> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
Yep. This is actually something I was hoping to work on over the past few
weeks, but other responsibilities have prevented it. If you'd like to take
a crack at it, that's be great. I think you'll find that you need to focus
only on the logic in libsvn_client/copy.c.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-08-27 18:30:00 CEST