patch conflicts (Re: svn commit: r928900 - /subversion/trunk/notes/wc-ng/conflict-storage)

On Mon, Mar 29, 2010 at 09:10:46PM -0000, gstein_at_apache.org wrote:
> Author: gstein
> Date: Mon Mar 29 21:10:46 2010
> New Revision: 928900
>
> @@ -187,3 +208,6 @@ hunk as written to the .svnpatch.rej fil
> ### The pristine store needs all references to be stored in a DB column.
> ### To support this we would need an extra table.
>
> +### gstein: why keep the PATCH_FILE_ABSPATH? couldn't that be rm'd at
> +### some point after the attempted 'svn patch'? and doesn't this
> +### obviate the future possibility of patch from stdin?
>

I meant to include a bit of information that tells the user which
patch caused the problem. The best identifier I came up with is the
name of the patch file. It does not matter if the file still exists.
The name just serves as a reminder, and the user will probably know
how to get the patch back if it's already been rm'd.

So the idea is that svn info would show something like the following,
analogous to what it shows for tree conflicts today:

$ svn info foo.c
[...]
Patch conflict (rejected hunks from /tmp/issue-42-fix.diff):
        @@ -1,5,+1,5 @@
        @@ -20,5,+20,2 @@

If the patch came from stdin (note that I don't currently plan to add
support for this), I'd just make it say:

$ svn info foo.c
Patch conflict (rejected hunks from <stdin>):
        @@ -1,5,+1,5 @@
        @@ -20,5,+20,2 @@

And svn status would show just the hunk headers:

$ svn status
C foo.c
> @@ -1,5,+1,5 @@
> @@ -20,5,+20,2 @@

This way we don't need yet another C column to tell apart patch
rejects from text conflicts.

Am I making sense?

Stefan
Received on 2010-03-30 16:15:30 CEST