On Mon, Sep 15, 2008 at 03:23:36PM +0200, Stefan Sperling wrote:
> Say there was a textdelta for file foo.c in revision 4,
> and the file foo.c was created in revision 3.
>
> I am merging revision 4 into a branch.
>
> In the current implementation, revision 4 (the textdelta)
> will be skipped, but mergeinfo will claim that revision 4
> was merged! (See attached recipe script for reference.)
>
> /trunk:2,4
>
> Instead, I'd expect explicit mergeinfo on foo.c with
> revision 4 omitted:
>
> /trunk/foo.c:2
>
> or even:
>
> /trunk/foo.c:2,!4
>
> if such "negative mergeinfo" was feasible -- it may be easier
> to record "We failed to apply revision X to path Y" rather
> than determining the answer to the question "Which revisions
> in the merge range could not be applied to path Y?" after
> a merge of some arbitrary revision range.
Stephen Butler pointed out to me that the client-side merge
editor does not know which revisions individual changes come from.
The merge only knows the merge-left and merge-right revisions, and
gets the resulting diff without knowing how the diff was composed.
So the client may not even know which particular revision fails
to apply.
Thoughts?
Stefan
---------------------------------------------------------------------
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-15 22:09:21 CEST