On 11/7/07, Paul Burba <pburba@collab.net> wrote:
> 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?
Can D be done? I would be in favor of D over the other options. I
would not be against auto-correcting in cases where we are just
helping the user and not potentially auto-correcting a typo or
mistake. That is why I generally favor D. If the data they enter is
not perfect it is kind of impossible to know if we are helping or
hurting them by "fixing" the problem.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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:25:17 2007