[RFC] QA of manually set svn:mergeinfo

Users can manually set the svn:mergeinfo property with svn propset.

How far should we go to save them from themselves?

1) Today if the mergeinfo isn't validly formatted we let the ps succeed,
but attempts to commit it (or merge into it) fail:

>svn ps svn:mergeinfo "jrandom" merge_tests-63\A_COPY\D\G
property 'svn:mergeinfo' set on 'merge_tests-63\A_COPY\D\G'

>svn merge %URL63%/A/D merge_tests-63\A_COPY\D -r3:8
..\..\..\subversion\libsvn_subr\mergeinfo.c:418: (apr_err=200020)
svn: Pathname not terminated by ':'

>svn ci -m "" merge_tests-63
Sending merge_tests-63\A_COPY\D\G
..\..\..\subversion\libsvn_client\commit.c:916: (apr_err=200020)
svn: Commit failed (details follow):
..\..\..\subversion\libsvn_subr\mergeinfo.c:418: (apr_err=200020)
svn: Pathname not terminated by ':'

We do allow the propsets however:

2) Overlapping ranges with the same inheritability

>svn ps svn:mergeinfo "/A/D/G:1,5-7,7-9" merge_tests-63\A_COPY\D\G
property 'svn:mergeinfo' set on 'merge_tests-63\A_COPY\D\G'

3) Overlapping ranges with differing inhertiability

>svn ps svn:mergeinfo "/A/D/G:1,5-7,7-9*" merge_tests-63\A_COPY\D\G
property 'svn:mergeinfo' set on 'merge_tests-63\A_COPY\D\G'

4) Unordered ranges

>svn ps svn:mergeinfo "/A/D/G:1,7-9,5" merge_tests-63\A_COPY\D\G
property 'svn:mergeinfo' set on 'merge_tests-63\A_COPY\D\G'

These last three can be merged into (with unpredictable results in some
cases) or committed.

In the second and fourth cases we could correct the mergeinfo to
"/A/D/G:1,5-9" and "/A/D/G:1,5,7-9" respectively, but in the second case
any assumption is going to be wrong for somebody ("did the user mean r7
to apply only to 'merge_tests-63\A_COPY\D\G' or to all its children as
well?").

A few options...

A) Consider cases 2 - 4 as invalid svn:mergeinfo and fail during a
commit or merge the same way as case 1.

B) Auto-correct the mergeinfo in cast 2 and 4 immediately following the
propset. Handle case 3 the same as case 1 today (no error until merge
or commit).

C) Auto-correct the mergeinfo in cast 2 and 4 immediately following the
propset. Fail case 1 and 3 on the propset attempt.

D) Fail all four cases on the propset attempt.

I really prefer D! In cases 1 and 3 it lets the user know as soon as
they try an completely bogus propset rather than waiting until a commit
or merge. In cases 2 and 4 it prevents a silent change to the property
they just explicitly set.

Thoughts, objections to D?

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 7 17:20:50 2007