On Thu, Mar 19, 2009 at 09:18:34AM -0700, Todd C. Gleason wrote:
> 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
What is r1968? Do you mean r1963?
> 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).
You mean you manually edited file X and re-did the changes that you
initially made and committed as r1059?
> 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.
>
>
> 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.
How did you handle the conflicts during the final merge from branch? Did
you postpone at merge time?
> 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".
You can merge just one file from one revision: svn merge -c$REV
svn://path/to/source/file (svn://)path/to/dest/file. This will create
mergeinfo on the destination file.
> 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).
You can do this too. Same as my above command line but add
--record-only.
> 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.
First, are you sure the changes are exactly identical? If your manual
edit differs by so much as a single space, then Subversion is correct to
mark the section as being in conflict. Even if your changes were
identical, you might get a conflict anyway because you've done something
confusing: If you do a "merge" behind Subversion's back and don't report
it it (by updating the mergeinfo for the affected file), how can you
expect Subversion to know what you did?
> 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."
I agree that it's a little strange that Subversion quit merging
revisions after it encountered a conflict, but this might be expected,
especially if later revisions tried to make changes to the section
already marked as conflicted.
hth,
tyler
Received on 2009-03-20 16:30:03 CET