0

This example is from SVN 1.8.

We use the common technique with a trunk and feature branches. Typically a feature branch is created by branching trunk. The feature branch is continually kept up-to-date with trunk by merging changes from trunk to feature branch (rebase). When development in the feature branch is finished the content is merged back to trunk.

When the feature branch is merged back to trunk all changes to the feature branch, including those created by rebase, is recorded in svn:mergeinfo property of the file/folder in trunk. One consequence of this is that files and folders which have not been updated in the feature branch (except by rebase) is marked as changed (property only) when the feature branch is merged back to trunk.

Why is this necessary? The trunk log shows that these folders/files where changed when the feature branch was merged back to trunk despite that no folder/file content has been changed in the feature branch relative to trunk. This is quite confusing for our developers because TortoiseSVN shows that a lot of folders/files they haven't changed has been updated. Is this really the desirable behavior?

user2052153
  • 129
  • 10
  • What is this "rebase" you're talking about? SVN doesn't have such a command that I know of... – Ben Jun 10 '16 at 17:00
  • Oh nevermind that's what you're calling your trunk-to-branch merge. – Ben Jun 10 '16 at 17:01

1 Answers1

0

SVN is not actually very smart about merge tracking. It only really pays attention to, "what versions did you tell me to merge" not "where did the changes in these versions come from originally". You told SVN to merge an entire branch; so SVN did just that, logging every version on that branch as merged.

That said, you can take steps to eliminate some of the overhead. If you always do merges only from the top-level folder for your project, you will only even have mergeinfo on that top-level folder; you won't have a bunch of subfolders and files with the property set. It sounds like you must have cherry-picked specific files and folders within the project while doing your "rebase" merges. If you can avoid doing that, your log data should look a lot cleaner, with only the top-level folder properties changing for your final merge.

Ben
  • 8,725
  • 1
  • 30
  • 48
  • Nope, I haven't done any cherry-picking of subfolders. At least to me it seems like SVN updates svn:mergeinfo for every subfolder/file of the branched/merged folder. Lets consider the following scenario. 1. Feature branch created to /branch 2. trunk/foo/bar.txt is updated 3. Rebase, i.e. merge entire trunk to branch. svn:mergeinfo for branch/foo is updated. 4. Merge entire branch back to trunk. Now svn:mergeinfo for trunk/foo is updated with the info that this folder has been merged from /branch/foo – user2052153 Jun 11 '16 at 17:07
  • "At least to me it seems like SVN updates svn:mergeinfo for every subfolder/file of the branched/merged folder" - I mean every changed subfolder/file – user2052153 Jun 11 '16 at 17:26
  • I think I've seen this before when merging into a sparse working copy that does not contain all the paths being merged. Does that apply in your situation? Otherwise that's not normal. – Ben Jun 11 '16 at 18:04