> There is one serious problem with this solution: It won't work if r4
> affects 'trunk' directly (e.g. a prop change on 'trunk').
>
> Because in that case the prop change in r4 will be merged into
> 'branch' so we need to record it in 'branch's mergeinfo. But if we
> add '/trunk:4' to 'branch's mergeinfo that implies that
> '/branch/foo.c' got r4, which of course it didn't since 'foo.c' isn't
> present yet. I mentioned this problem earlier in this thread - see
> "Befitting a "big ugly hack" there's a problem".
>
> Do you understand why this is a problem? If not let's resolve that first!
We've missed this problem. We understand it and the proposed solution
isn't viable because of it. Sorry.
>> Only part of this revision is merged. It's better
>> than write that r4 is merged "non-inheritable", because
>> 'non-inheritable' merged revisions make no sense for an average user.
>
> So normal 'inheritable' mergeinfo makes sense to users, but
> non-inheritable mergeinfo doesn't? Heck, I'm not very fond of
> mergeinfo as an inheritable property, but it's what we have at the
> moment and I don't see how non-inheritable properties are
> fundamentally more complex.
We're not trying to say that users understand inheritable and don't
understand non-inheritable mergeinfo records. The problem is in the
level of abstraction (keep in mind that we're talking about "very
average Subversion user").
* What's happened: revision r4 is merged incompletely.
* What's recorded: non-inheritable mergeinfo for target and
inheritable mergeinfo for all siblings of the skipped path.
It's not so easy to figure out "what's happened" from "what's
recorded". It will be far more easy for users if "incomplete merge"
will be recorded explicitly.
That's what I'm trying to say.
> Also, am I to take it that you are proposing removing non-inheritable
> mergeinfo?
I'm not proposing to completely remove non-inheritable mergeinfo. I'm
arguing to find a better solution for this problem.
> Unless we are planning on disabling merge-tracking when
> performing shallow merges (i.e. with depths other than infinity), when
> merging into shallow working copies, working copies with switched
> subtrees, or WCs with subtrees missing due to authorization
> restrictions, then we need non-inheritable mergeinfo. These problems
> and the problem we are discussing in this thread are all subsets of
> the same basic issue: How do we account for subtrees that are
> (potentially) affected by a merge but that are missing from the
> working copy. The solution to this class of problems is currently
> non-inheritable mergeinfo. I'd like whatever solution is settled on
> for this problem to the solution we use for this whole class of
> problems.
Am I understand correctly, that with the current approach explicit
mergeinfo will be written to all siblings of skipped (/switched/etc.)
path? There is a problem with access rights management if it is.
Write access to some siblings of skipped path can be restricted. In that case:
A) user will be disappointed because commit will be prohibited;
B) inconsistent mergeinfo will be committed even if user will manually
remove mergeinfo on write-restricted paths.
Write-restriction rarely occurs in the open-source development but
it's a common practice in "the industry". And write-restricted users
are usually not-a-very-experienced programmers. And they can be not
very familiar with advanced Subversion topics.
> Note: This example assumes the ideas proposed in
> http://svn.haxx.se/dev/archive-2008-09/0443.shtml have been
> implemented (but that is hardly a done deal). Specifically, r3
> doesn't affect 'bar.c' so that revision is not recorded in 'bar.c's
> mergeinfo. Not a big deal, but worth noting.
Ok.
>> Now user can find out that r4 is still not merged completely
>
> Seriously? Can you state the general steps one would use to determine
> this? Before you do, keep in mind what "real" mergeinfo looks like;
> go run svn pg svn:mergeinfo -vR on any of the Subversion branches to
> see what I mean. Then tell me how easy it will be to spot a single
> revision or revision range that exists on one subtree but not on the
> others.
As you pointed, the whole proposed approach is not viable (because of
possible target's properties change). But the initial idea will be as
follows:
* user sees that mergeinfo is recorded to some sub-paths but not
recorded to the target;
* this means that the revision isn't merged completely;
* user is not requested to clearly understand the difference between
inheritable and non-inheritable mergeinfo.
What do you think about following solution? In the discussed example
we can do the following:
1) record on target that r4 is merged incompletely
2) record r4 on all affected (and not skipped) paths
Generated mergeinfo can look like this:
Properties on 'branch':
svn:mergeinfo
/trunk:4! (r4 is merged incompletely)
Properties on 'branch/bar.c':
svn:mergeinfo
/trunk/bar.c:4
Properties on 'branch/subdir':
svn:mergeinfo
<null>
I understand that this approach requires introduction of additional
semantics. But I just want to investigate, is it viable or not.
> I'd go as far as to say that the non-inheritable marker '*' makes it
> somewhat easier to spot what revisions haven't been merged completely.
Yes, it can be. But there are following problems:
1) write-restriction problem that's described above;
2) it's better to see 'what's changed' than 'what's not changed'.
Usually, the count of changed paths is smaller than count of unchanged
ones.
>> on branch and merge it once again.
>>
>> We will get the following mergeinfo:
>>
>> Properties on 'branch':
>> svn:mergeinfo
>> /trunk:3,4
>> Properties on 'branch/bar.c':
>> svn:mergeinfo
>> <empty>
>> Properties on 'branch/foo.c':
>> svn:mergeinfo
>> <empty>
>> Properties on 'branch/subdir':
>> svn:mergeinfo
>> <empty>
>>
>> Note than now we can elide mergeinfo on 'branch/bar.c'.
>
> Actually no, until we rewrite the elision code this won't work.
> Because when you perform the merge above, at the end of the merge,
> before elision is attempted you will have mergeinfo that looks like
> this:
I agree. But I think it's not a good idea to discuss elision in
details in this thread.
--
Danil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-23 00:02:23 CEST