55

Branching sources for release cycle is one of common source management scenarios. Merging as soon as possible is a good practice. Thus we have a human factor: branch is closed, but someone forgot to merge something back to trunk.

Q: Is there a "one click" way to get all revision numbers that were not merged from branch X to trunk?

(Note: I do not need these revision numbers to find what to merge, I need them to create automated validation, that would remind people to make sure they did not forget to merge something to trunk. Merging itself is not an issue.)

It seems like svn mergeinfo command fails to help here. Passing branch and trunk roots will fail if merge was performed not on root level (and it is a common scenario).

Scripts, tools any kind of svn hooks as a solution are welcome.

P.S.

Latest version of SVN. No need to argue how common or good this scenario is ;)

approxiblue
  • 6,982
  • 16
  • 51
  • 59
Dandikas
  • 2,426
  • 2
  • 24
  • 32
  • I am amazed that the question yet has no answer! It sure was a hard thing to do before mergeinfo was introduced, but now I was expecting an answer like "stupid, you should learn how to google, here is the link". Strange and yet disappointing. – Dandikas Feb 09 '10 at 14:57

11 Answers11

70

You can do this super easily if you're using a relatively newish version of Subversion (1.5 or higher, I think) with the mergeinfo sub-command.

svn mergeinfo --show-revs eligible svn://repo/branches/your-branch-name svn://repo/trunk

This will show you all the revisions that are eligible to be merged to the trunk from the branch "your-branch-name".

Source: http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.mergeinfo.html

tmont
  • 2,562
  • 20
  • 15
  • @tmont from question: "It seams like svn mergeinfo command fails to help here. Passing branch and trunk roots will fail if merge was performed not on root level (and it is a common scenario)." --show-revs eligible only changes list from "what was merged" to "yet to merge" but mentioned sub folder commit failure is still there. – Dandikas Feb 08 '10 at 10:53
  • 7
    "and it is a common scenario" -> it's a common error to merge / branch at different levels! ALWAYS merge at that level where your branch started. ALWAYS. – bebbo Apr 25 '13 at 16:17
  • 3
    There is a `-R` (recursive) option to the svn mergeinfo command (at least in the current version) which should make it include merges performed lower down. We try to always merge at the top level (commits can be performed at lower levels, or including only files in a certain directory, but merges always at the top) so I haven't really tested it. – Adam Aug 23 '14 at 10:25
  • I was confused by terminology for a moment, "level" here means "directory level", right? – Ed Randall Oct 27 '15 at 12:52
7

Short answer: I don't think so.

Long answer: I ended up writing a python script to answer this question. Whenever developers merge a changeset they're required to put "merged rXXX" in the log message. (This from before svn:mergeinfo existed) The script parses all live svn branches + trunk and recursively scans all "merged" links, outputting a per-developer list of changes they haven't merged.

[update] The answer from @tmont is better now that everyone has a svn version that supports svn mergeinfo --show-revs eligible and svn merge --record-only for those times when you want to record the logical fix only.

Nathan Kidd
  • 2,919
  • 21
  • 22
  • @Nathan Kidd this is exactly what I am looking for! Only difference is that I expect it to work without special comment, as now we have svn:mergeinfo property in place. – Dandikas Feb 09 '10 at 07:29
  • 1
    @Dandikas If I were to write it again I'm not sure I'd use svn:mergeinfo anyway. The reason is our concern is not really that a particular diff gets merged, but that the logical fix for the issue is applied. Sometimes if a branch diverges enough we'll fix the issue and mark it 'merged' but in fact we didn't apply any of the original diff; a separate approach was used to fix the same issue. The manual log message approach lets you do this, svn:mergeinfo doesn't so much. – Nathan Kidd Feb 09 '10 at 16:41
  • 1
    got your point. Our work-flow is slightly different in the way that merges are performed as soon as possible. I.e. if developer commits fix to a branch (be it one commit or several, that accomplishes the fix) he than immediately merges them to trunk. This approach has many strengths and one serious weakness - human factor. Any fix in a branch is potentially performed under more pressure with less available time. Yet we still must assure, that people (devs are people right) know when they might have forgotten to merge something. – Dandikas Feb 10 '10 at 07:52
  • 1
    There is a solution to the merginfo problem. That is "svn merge --record-only" to record those merges which were done at a different part of the tree, or where there was no actual merge but rather an application of the logical fix. Then you can use "--show-revs eligible" to get a list of things still waiting to be merged. – Ari Maniatis Dec 21 '11 at 04:13
2

I realize your case is probably too late for this, but what I do for this sort of thing is to establish a convention for the merge commits so they're identifiable later. For example "Merging [1234]: ...(full commit log of 1234)...". Then I can parse it out of svn log with a script later.

To make sure your whole team does it, make the merge convention into a script and put it in your project. (e.g., ./scripts/merge 1234). People will generally even appreciate this, doubly so if the script makes merges easier than the raw svn command would be by doing things like figuring out the source url automatically

Good luck.

Mat Schaffer
  • 1,634
  • 1
  • 15
  • 24
  • This sounds like what is needed, except that I do not want to make a convention on comments since we have mergeinfo property starting from SVN v1.5 – Dandikas Feb 09 '10 at 07:43
  • I hear you. I wish that worked too, but I have yet to have the 1.5 merge handling do anything other than complicate the situation. – Mat Schaffer Feb 09 '10 at 18:50
1

I wouldn't worry about the specific change numbers that need to get merged, but rather just look at the diffs:

First, bring the side branch up to date with trunk (or see what would be merged):

cd branch-dir
svn merge --reintegrate http://svnrepo/path-to-trunk .
svn ci -m'making this branch current'

cd ../trunk-dir
svn merge --dry-run http://svnrepo/path-to-trunk http://svnrepo/path-to-branch .
svn ci -m'merging in all unmerged changes from <branch>'

Remember, svn merge commands look just like svn diff commands - you create a diff/patch, then apply that to a particular location. That merge command above is simply saying "take all the differences between trunk and the branch, and apply them to a working copy of trunk". So you could just as easily change that second merge command into a diff for your mail notification.

Don't forget to check the diffs before committing in each case, to be sure that nothing bad has happened. You may also have to resolve some conflicts.

Ether
  • 53,118
  • 13
  • 86
  • 159
  • @Ether that's a good short explanation on merge ;) I do know how to merge(i.e. that was not the question). I am interested in source maintaining, and want to get an automated answer on question "what was not merged". The answer would than be mailed to people who forgot to merge. – Dandikas Feb 08 '10 at 07:22
  • @Dandikas: I've amended my answer to be more clear what I meant. – Ether Feb 08 '10 at 16:39
1

I'm sorry I don't have my SVN server up at home to test this right now, but could the command:

svn log --verbose

Which you could parse? I'm not sure the output after you merge back to main, but you might be able to parse through (using a script, which I don't have as I'm the only one using my SVN server) the log and read all the files that have been checked in, and then look for a keyword indicating that the file has been merged to main?

I'll try to check it out sometime tonight when I get home if I have some time.

onaclov2000
  • 5,741
  • 9
  • 40
  • 54
0

I'm enjoying your thread after 3 years of it being created. And I believe there is still no solution for your task in the form you put it :)

What I found though in the $ svn help merge is the advice not to do sub tree merges:

If you want to merge only a subtree, then the subtree path must be included in both SOURCE and TARGET_WCPATH; this is discouraged, to avoid subtree mergeinfo

So I guess the solution is to break your "common scenario" of doing subtree merges.

It would be mandatory to establish some control for merge operation, as otherwise anybody having Read access to one branch and Write access to another can do the merge from first to second. So the actual question is - how to control subtree merges ))

Ivan
  • 9,089
  • 4
  • 61
  • 74
0

I have written Java Web Application using Wicket and SVNKit for finding not merged revisions between branches, it could be customized to do whatever you want... link

screeno

Meo
  • 12,020
  • 7
  • 45
  • 52
0

For that reason CVS created a tag to mark a root of branch :) For SVN that should look like:

+ trunk / project1
+ tags / project1-b1-root
+ branches / project1-b1

Notes:

  1. Tag project1-b1-root and branch project1-b1 are created at the same time from trunk.
  2. Nobody should commit to project1-b1-root (you can restrict this operation for tags/ path).
  3. When everybody claimed, that he has put everything to the trunk, you make a diff between project1-b1-root and project1-b1 and try to apply it to trunk: the changes, which are already applied, will be silently skipped, for the rest you will see the difference or collisions.
dma_k
  • 10,431
  • 16
  • 76
  • 128
  • @dma_k 3 step requires human interaction. I really need something exactly like svn mergeinfo that returns a simple list of revisions merged (or not merged). In your scenario after getting merge results further manual investigation is needed to find out what revisions were not merged and who is the author. – Dandikas Feb 08 '10 at 07:44
0

Will svn merge --dry-run give you the details you need?

Adam Liss
  • 47,594
  • 12
  • 108
  • 150
  • nope :( dry run will tell if running merge is going to produce conflicts. Again, you can than try to find out revisions that were not merged, but it's more a game not a "one click" action that could be scheduled for automated run on branch closure. – Dandikas Feb 08 '10 at 13:30
0

Due to the lack of a silver bullet, the disciplined way is to keep a note of what has been merged and from where.

amit kumar
  • 20,438
  • 23
  • 90
  • 126
  • True as long as there are < 10 developers working on the same project. With a big teem you either change coding work-flow or do the check manually(sux). – Dandikas Feb 09 '10 at 07:35
  • 1
    Nooo! Due to the lack of silver bullet, one must develop it. Best procedure is Working Code. – Pavel Radzivilovsky Jan 06 '11 at 15:34
  • @Pavel If there are many other interesting things one wants to develop, for this issue one may like to switch to git instead. – amit kumar Jan 08 '11 at 12:34
0

Based on Ether's reply above, from the branch you want to check for unmerged revisions

svn merge --dry-run http://svnrepo/path-to-merge-source .  \
| grep Merging                                             \
| sed 's/--- Merging//'                                    \
| sed 's/into.*//'                                         \
| sort -u                                                  \
| sed 's/ through r/:/'                                    \
| sed -e :a -e N -e 's/\n//' -e ta                         \
| sed 's/ r/ -r/g'                                         \
| sed 's|^|svn log http://svnrepo/path-to-merge-source |'
Community
  • 1
  • 1
Malcolm
  • 1,239
  • 1
  • 14
  • 25
  • 1
    If you find yourself using a grep and sed like in your 2nd and 3rd lines, try this simple optimization: sed -n 's/--- Merging//p' – Nathan Kidd Feb 01 '13 at 16:27