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

> While on that topic: Danil - I noticed in your original patch
> svn_client__get_wc_mergeinfo was tweaked to support inheritance of
> mergeinfo across mixed-revision boundaries. It seems to me we might
> easily inherit incorrect mergeinfo if doing this, am I missing
> something?

First of all, it surprising how easy we can get mixed-revision working
copy. It appears just after plain commit. User needs to update after
every commit to have his copy always in the single-revision state.
Maybe it's a good practice but I don't think that majority of users
follow this way. So we can treat the most of real working copies as a
mixed-revision ones.

Other question is how we can rely on any mergeinfo stored in the
working copy. For example, we copy file1.txt to the dir1\file1.txt.
There is no of any mergeinfo in the working copy and we don't record
anything for the new dir1\file1.txt. But dir1 have some explicit
mergeinfo in the repository (as a result of cherry picking, for
example). And we will get incorrect mergeinfo for the new
dir1\file1.txt when the working copy will be updated.

But I wonder how it's really important to have absolutely correct
mergeinfo on the copied file or folder (except such cases when we make
local branch etc). What is the use case when things become wrong
because of the fact that we rely on a mixed-revision working copy
(with the original patch) or on a not-up-to-date working copy (in the
original trunk)? And how empty mergeinfo is better than null-mergeinfo
in that case?

-- 
Danil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org