You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Todd C. Gleason" <tg...@impac.com> on 2009/03/19 16:18:34 UTC
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@subversion.tigris.org].
RE: svn merge ignored a revision
Posted by "Todd C. Gleason" <tg...@impac.com>.
> 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@subversion.tigris.org].
Re: svn merge ignored a revision
Posted by Tyler <ty...@cryptio.net>.
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