top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Consequence of not using --reintegrate option in SVN merge

0 votes
597 views

We have a situation where a few folks don't use --reintegrate option when performing SVN merge, while others do.
Whats
1- the consequence of not using --reintegrate option; can the feature branch continue to svn merge to trunk the 2nd time and thereafter ?
2- the impact on those feature branches that do use --reintegrate option; from what we read in the manual, that one cannot use this feature branches anymore.

posted Aug 15, 2013 by Naveena Garg

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+2 votes
merge issue - files not updated because of svn commits fail

We are using svn 1.6 - we tried merging from Trunk to a feature branch using svn merge (automatically). We just found out that some files are not updated with the merges but mergeinfo has already indicated and ci with the messages that those files are merged. We like to perform svn merge again using the same revision number from the trunk to the feature branch would svn refuse simply because it was merged "successfully" before ?

Are there side effects in applying svn merge again on the same revision numbers from the mergeinfo property ?

+1 vote
SVN merge for large number of files

I have 30 files that I want to merge, but I do not know which would be the easiest and much efficient and save way to do so.
I have the main production line Z and two other branches X and Y. All of the branches are still in production since X and Y are minor releases. Therefor on a time frame they are look this:
Z - trunk, next major releaseY - next minor release (Z - Y = small changes)X - used to make patches for an old release
The idea is that between Z and Y arent so many differences, but between X and Y(or Z) are plenty. There was a fix in the X branch that needs to be back ported into Z and Y. I am using svn merge to merge changes from X to Y, but because of the big differences I think it adds even code that could not be useful in Y, showing as conflicts just a few code blocks/file. which would be the best approach for such a merge?

+5 votes
Can svn merge --record-only be applied multiple times on a revision number?

Are there side effects from applying the same svn merge --record-only on the same revision number and a new commit each time it is applied ?

Would there be issues with SVN mergeinfo and/or SVN in general if one keeps applying svn merge --record-only on a revision number repeatedly and commit in a svn merge --record-only followed by commit followed by svn merge --record-only followed by commit and the next cycle begins ? Its not an infinite loop svn merge; it would stop at some point.

+1 vote
svn mergeinfo and svn merge

We are using 1.6 SVN. We like to svn merge from our branch A to trunk.We have been diligent in svn merge from trunk to A.These svn merges from trunk to branch A also include --record-only merges too, in addition to regular merges. Development on branch A has stopped.Now we like to merge branch A to trunk using --reintegrate option.B ut we dont know what to expect if using this option fails on us.

1) Suppose svn merge --reintegrate fails on us on a working copy that has all the mergeinfo list information. Could we perform a clean co of branch A into another working copy and then perform svn merge --reintegrate to trunk there ? Will we get more conflicts simply because the new working copy doesnt have the mergeinfo list like the first working copy of branch A ? Will this plan B work ?

2) How do we resolve conflicts during svn merge --reintegrate process ? Would you share the steps for us to make the merge go smoothly ?

3) Is mergeinfo a global or local property ? it seems that whenever a new checkout is done, mergeinfo list matches up with other working copies of the same branch.

+2 votes
Svn merge that deletes files fails with svn

While merging branch back to trunk I constantly get the error in the subject. Note that x/y/z has svn:mergeinfo property. The property was not added on the branch, but it was already there when the branch was created. Subsequently x/y/z is deleted on branch.

The error is generated when running: "svn merge ^/branches/mybranch" on a trunk working copy.

Sounds to me like a bug, svn tries to update the mergeinfo on the deleted path. Is that so ?

...