Re: [PATCH] no mergeinfo on 'mergeinfo NON-affecting' wc-to-wc copy

On Wed, Sep 10, 2008 at 10:37 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Mark Phippard wrote:
>> On Wed, Sep 10, 2008 at 10:27 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>
>>>> 2008/9/10 Danil Shopyrin <danil_at_visualsvn.com>:
>>>>> Hi!
>>>>>
>>>>> Here is the patch that is trying to fix on of the problem discussed at
>>>>> http://svn.haxx.se/dev/archive-2008-08/0793.shtml
>>>>> [[
>>>>> 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.
>>>>> ]]
>>>>>
>>>>> The general idea of the patch is as follows: we don't produce any
>>>>> mergeinfo record if we [definitely] know that it's unnecessary. The
>>>>> patch should ease the pain in the most cases. For example, it's not
>>>>> needed to worry about mergeinfo in the cases when:
>>>>> a. copy is performed within a working copy (it's just a 'local file
>>>>> rename because of refactoring')
>>>>> b. there is no merges except ones on the trunk/branches level (or
>>>>> there is no merges at all)
>>>>>
>>>> The patch looks correct, but I think it's more complicated than it
>>>> needs to be. I'd rather not put the extra checks in a different
>>>> function, and I don't think you need to extend
>>>> svn_client__get_wc_mergeinfo().
>>>>
>>>> In propagate_mergeinfo_within_wc(), we need to do the following:
>>>>
>>>> 1. Get the mergeinfo for the source. If it's explicit, not inherited,
>>>> we're done, there's nothing to propagate, because the destination
>>>> already has the same explicit mergeinfo as the source, as a result of
>>>> the copy. Currently, propagate_mergeinfo_within_wc() calls
>>>> calculate_target_mergeinfo(), we can replace this with a call to
>>>> svn_client__get_wc_mergeinfo().
>>>> 2. Figure out which path the destination inherits mergeinfo from, if any.
>>> ...making sure to honor the wc-to-wc copy's promise not to talk to the
>>> repository. If, in this scenario, you don't find any inheritable
>>> mergeinfo in a working copy parent, you must not assume that *no*
>>> parent has mergeinfo (since maybe you only checked out /trunk/project
>>> but it's /trunk that carries the mergeinfo). Unless you can otherwise
>>> determine that's safe not to do so in this case, you must continue to
>>> set the empty mergeinfo property on the copy destination.
>>
>> Is it possible to do the logic at commit time and discard the property
>> if it is not needed?
>
> I trust you mean, "to *also* do the logic at commit time"? We already
> discussed how delaying the logic altogether could mean corrupting merges
> made into a copied-but-uncommitted directory. And I would suspect that
> introducing the commit-time mergeinfo calculation has its own problems (at
> the very least, WC schema changes to persist the previously calculated
> value, complexity to ensure that we aren't blowing away a user's 'svn merge
> --record-only' results, etc.)
>
> It suspect it can be done. I suspect it comes with a great price of
> complexity and special-cased-ness.

Vlad seems to have a valid point that this does not even need to be
done. But what I was suggesting is that the way I think this works
today is that we currently create empty mergeinfo and at commit time
some work is done to fill in the mergeinfo with the right values.
Maybe I am wrong about that? But what does not happen is any logic to
determine that the property was not needed and discard it.

The commit time part is just about waiting until we have a repository
connection which is why I thought we created the empty mergeinfo in
the first place.

Anyway, I prefer Vlad's solution anyway. As I have said many times, I
think we could just chuck out this whole check and never create
mergeinfo and it would be better than what we have today. The logic
Vlad suggested would be the ideal and seems doable.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org