svn merge ignored a revision

This is a corner case, and may be well-known, but I wanted to mention it
to make sure.

I recently ran a merge from a branch to the trunk, identifying all the
desired revisions to merge over. One file (call this "file X") ended up
in conflicted status, but once I resolved the conflict, the file was no
longer even modified. When I tried to compile against it, I got an
error, and then I noticed that Svn hadn't merged in one of my specified
revisions. The timeline for this is below:

Trunk Branch

                                                R1059 modified (several
files including file X)

                                                R1210 modified (file X
only)

                                                R1963 modified (several
files; in file X, changes were adjacent to R1059's)

R1977 merged including r1968

          Merge info supports this BUT

          I manually modified the commit

to include R1059 changes

made in file X ONLY

and did not update mergeinfo

(see below).

R2037 modified (file X)

R2189 final merge from branch,

specifying R1059 and R1210 but not R1963.

          R1210 changes did not merge in.

svn said:

--- Merging r1059 into '.':

C file X

--- Merging r1210 into '.':

          G file X

          Conflicted filenames looked like

          file X.merge-left.r1058 and

          file X.merge-right.r1059

          Resolved conflicts. Manually integrated R1210.

Server: Svn 1.5.2 under Apache with NTLM running on Windows 2003
Server.

Client: Svn 1.5.5 under Windows XP using https. (http-library = serf)

So the question is: Did my manual merge of r1059, without updating
mergeinfo, throw off svn? It looks like svn sort of stopped at r1059,
but it gave no indication whatsoever that it hadn't merged R1210, which
is what worries me.

I'm also worried by the fact that, after I made the related R1059 and
R1963 changes (to multiple files each), and in order to merge R1963 to
trunk I had to manually merge part of R1059, I had no way to indicate
this. The only way I know I could have avoided this would have been to
have split apart my R1059 and R1963 commits, which would have required
foreknowledge I didn't have.

So the problems I see here are:

1. The granularity at which you can run a merge. On occasion I
know people would like to say "just merge this one file from that
revision".
2. The granularity at which merges can be recorded, even if you did
so manually (AFAIK you can't say "I merged r# for file X only" so in
R1977 I don't know what I could have done any better).
3. The merge in this case identified the duplicated R1059 code in
trunk as a conflict rather than ignoring it (it was completely identical
code, as evidenced by the fact that resolving the conflict left me with
a file identical to the working base). Usually (in testing) I have seen
this sort of thing get ignored.
4. The merge silently failed with revisions after the one
generating the conflict (at least when the merge is run
non-interactively, which is what I did).
http://subversion.tigris.org/merge-tracking/func-spec.html seems to
mention this and says "In a post-1.5 release, the command-line client
will provide an interactive conflict resolution option to display some
context for each conflict in a path or property value, and prompt for
how to resolve it. The merge algorithm will attempt to continue applying
more of the requested merge after conflict is encountered, merging what
it can around the conflicted area of the WC, and possibly supporting an
option to complete the remainder of an unfinished merge operation after
conflicts have been resolved manually."

Is there anywhere that it looks like I made an error?

Also, I'm curious whether a svn 1.60 client and/or server improves this
scenario.

Todd C. Gleason

Senior Software Development Engineer

ELEKTA, Impac Software

719-481-1131

www.impac.com <http://www.impac.com>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1356354

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-19 17:20:37 CET