> 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?
Yes, sorry. It included several revisions.
> > 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?
In R1977 I did the automatic merge (svn merge) to pull in R1963, plus
manually merged (in other words, copy/pasted) the portion of r1059 that
applied to file X.
> > 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?
I passed non-interactive, thus postponing 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.
Okay, this is helpful to know.
> > 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.
Also good to know, thanks.
> > 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?
Once I was done with the conflict resolution, svn identified file X as
being unmodified. Thus, not off by a single space.
> > 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.
Thanks for the help. This does seem like a major flaw; an indication of
the failure would have been very helpful here. It seems that I could
have done three things to improve the behavior:
1. Manually deal with mergeinfo, or do the single-file merge recording
using the syntax you mentioned.
2. Run the merge once, getting the conflict, resolving it, and then run
the merge again.
3. Maybe if I ran the merge interactively I would have been given a
chance to resolve the conflicts, and then it would actually merge
subsequent revisions? But without any feedback of the problem, it's
hard to know if I'm in this scenario to begin with.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1365393
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-20 17:02:54 CET