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.
> > 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.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-08 23:56:41 CEST