Method 1
Yes , it is possible , and there is an open source project that does it!
check out https://github.com/liveperson/Auto-Merger
we are constantly working with it and it saves so much time and helps avoiding all those missed merges bugs.
Method 2
Run these commands at the root of a working copy of tests-passed whenever you have determined that a new trunk revision has passed the tests:
svn update
svn merge http://example.com/svn/myproject/trunk -r 0:<somerev>
svn commit -m "merged trunk revisions up to <somerev> into tests-passed"
Whenever you use the merge command, SVN will record the merges in the svn:mergeinfo property. So the above command should automatically determine which revisions in the range 0: are eligible for merging, excluding any merges that have already been done.
Like you said in a comment, conflicts are not expected. But sometimes I’ve seen unexpected conflicts occur anyway when merging a range of SVN revisions containing renames. To get rid of these conflicts, you can use the –accept theirs-full option with the merge command to always accept the trunk state.
Method 3
- If you merge from trunk to branch (in branch’s WC) order of parameters in mergeinfo is incorrect (reversed): shortened correct form have to be svn mergeinfo –show-revs eligible trunk (first parameter is SOURCE of merge, second – TARGET /default “.”/, i.e your WC)
- If you use Subversion, which has already support for mergeinfo, you can skip detecting range of “have to be merged” revisions – Subversion do it automagically on merge
- If you want in case of conflict always prefer changes from trunk, you can add it to merge command. As final result, your periodical sync-merge process will be single command inside WC of branch
svn merge <URL-OF-TRUNK> --accept "theirs-conflict"
- List of CUDA Aware framework in Machine Learning - December 25, 2024
- Complete Guide to Pytest: From Basics to Advanced - December 25, 2024
- Comprehensive Guide to Medical Tourism and Industry Insights - December 25, 2024