You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jacob Weber <ja...@jacobweber.com> on 2009/07/08 00:59:31 UTC
Ignoring ancestry in --reintegrate merge
I thought --reintegrate was basically like a diff, in that ignored ancestry. But this doesn't seem to be the case; it recognizes when files were deleted and re-created in the same place, and shows them as a conflict. Is there a way to avoid this?
Here's my situation. I had a project in CVS, which I converted to Subversion using cvs2svn. It has a trunk and a branch. All changes from the trunk have been merged into the branch before the conversion.
I wanted to set up the branch's mergeinfo property, so that Subversion knew that the trunk was already merged into it. So I did this:
svn co [branch]
svn merge --record-only [trunk]
This works correctly; a merge from trunk into branch shows no eligible revisions.
But when I try to reintegrate the branch back into the trunk, something strange happens. I start seeing lots of "R"eplaced files -- files that were deleted and re-created.
I think this happens because of the following sequence of events:
- Branch was created (in CVS)
- A file X was added to the trunk (in CVS)
- X was merged into the branch (also in CVS)
- Project was converted to Subversion
- Subversion didn't know that branch/X was copied from trunk/X. So it thinks it's a replacement.
So, is there a way for me to tell Subversion to ignore the files' ancestry when doing a --reintegrate merge?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369004
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Ignoring ancestry in --reintegrate merge
Posted by Bob Archer <bo...@amsi.com>.
> I imagine this syntax might do something different with the mergeinfo
> property. But if I delete my branch after the merge, and re-copy it
> from trunk (just like I would after a --reintegrate), it should be
> fine, right?
>
I would think so yes.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369725
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Ignoring ancestry in --reintegrate merge
Posted by Jacob Weber <ja...@jacobweber.com>.
> And this is about reintegrate:
>
> http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
That helps. According to that document, --reintegrate is essentially the same as "svn merge trunk branch", if I have the latest revision of the trunk merged into the branch.
And that syntax allows --ignore-ancestry. So it seems I'm able to do what I want. When I do "svn merge --ignore-ancestry trunk branch", it shows only the actual differences, without any of the R indicators for replaced files.
Which makes me wonder: why doesn't --reintegrate allow --ignore-ancestry? Wouldn't the use-case be the same?
Anyway -- thanks! This seems like a perfectly fine work-around for my problem (unless anyone can see any reason why it wouldn't work).
I imagine this syntax might do something different with the mergeinfo property. But if I delete my branch after the merge, and re-copy it from trunk (just like I would after a --reintegrate), it should be fine, right?
JW
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369570
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Ignoring ancestry in --reintegrate merge
Posted by Bob Archer <bo...@amsi.com>.
> Actually, I do have the branch-creation info. The SVN history looks
> something like this:
> r100: create branch (copied from trunk)
> r200: add trunk/X
> r300: add branch/X (because of a CVS merge, but it's not a SVN copy)
>
> Is there documentation somewhere that describes exactly what --
> reintegrate does? The manual tells you what it's used for, but doesn't
> go into much detail about the algorithm.
>
> Jacob
I have found this helpful... more about mergeinfo than --reinteragte.. but helps understand it more.
http://www.open.collab.net/community/subversion/articles/merge-info.html
And this is about reintegrate:
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369403
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Ignoring ancestry in --reintegrate merge
Posted by Jacob Weber <ja...@jacobweber.com>.
Actually, I do have the branch-creation info. The SVN history looks something like this:
r100: create branch (copied from trunk)
r200: add trunk/X
r300: add branch/X (because of a CVS merge, but it's not a SVN copy)
Is there documentation somewhere that describes exactly what --reintegrate does? The manual tells you what it's used for, but doesn't go into much detail about the algorithm.
Jacob
> > Here's my situation. I had a project in CVS, which I converted to
> > Subversion using cvs2svn. It has a trunk and a branch. All changes from
> > the trunk have been merged into the branch before the conversion.
> >
> > I wanted to set up the branch's mergeinfo property, so that Subversion
> > knew that the trunk was already merged into it. So I did this:
> > svn co [branch]
> > svn merge --record-only [trunk]
> > This works correctly; a merge from trunk into branch shows no eligible
> > revisions.
> >
> > But when I try to reintegrate the branch back into the trunk, something
> > strange happens. I start seeing lots of "R"eplaced files -- files that
> > were deleted and re-created.
> >
> > I think this happens because of the following sequence of events:
> > - Branch was created (in CVS)
> > - A file X was added to the trunk (in CVS)
> > - X was merged into the branch (also in CVS)
> > - Project was converted to Subversion
> > - Subversion didn't know that branch/X was copied from trunk/X. So it
> > thinks it's a replacement.
> >
> > So, is there a way for me to tell Subversion to ignore the files'
> > ancestry when doing a --reintegrate merge?
>
> I don't think so.--reintegrate goes back and figures out where the branch was created... and you may not have that info in your conversion. You might just have to do a traditional range merge and specify the revisions where the branch started deviating from the trunk.
>
> Then again, I have only been working with merges for 6 months so I'm still a noob at them.
>
> BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369158
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: Ignoring ancestry in --reintegrate merge
Posted by Bob Archer <bo...@amsi.com>.
> Here's my situation. I had a project in CVS, which I converted to
> Subversion using cvs2svn. It has a trunk and a branch. All changes from
> the trunk have been merged into the branch before the conversion.
>
> I wanted to set up the branch's mergeinfo property, so that Subversion
> knew that the trunk was already merged into it. So I did this:
> svn co [branch]
> svn merge --record-only [trunk]
> This works correctly; a merge from trunk into branch shows no eligible
> revisions.
>
> But when I try to reintegrate the branch back into the trunk, something
> strange happens. I start seeing lots of "R"eplaced files -- files that
> were deleted and re-created.
>
> I think this happens because of the following sequence of events:
> - Branch was created (in CVS)
> - A file X was added to the trunk (in CVS)
> - X was merged into the branch (also in CVS)
> - Project was converted to Subversion
> - Subversion didn't know that branch/X was copied from trunk/X. So it
> thinks it's a replacement.
>
> So, is there a way for me to tell Subversion to ignore the files'
> ancestry when doing a --reintegrate merge?
I don't think so.--reintegrate goes back and figures out where the branch was created... and you may not have that info in your conversion. You might just have to do a traditional range merge and specify the revisions where the branch started deviating from the trunk.
Then again, I have only been working with merges for 6 months so I'm still a noob at them.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2369091
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].