Development/Tools/svnmerge.py - Revision history

Neverendingo: Text replace - "" to ""

2011-06-29T20:50:26Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T20:38:52Z
Text replace - "<code bash>" to "<syntaxhighlight lang="bash">"

				
				
				
				
			
			← Older revision
			Revision as of 20:38, 29 June 2011
			
Line 194:
Line 194:
    
  This can be done by running ''svn merge''. Example:   This can be done by running ''svn merge''. Example:
− <code bash> + <syntaxhighlight lang="bash">
  cd korganizer   cd korganizer
  svn merge $SVNBASE/branches/KDE/4.2/kdepim/korganizer/views/agendaview/ -c934407   svn merge $SVNBASE/branches/KDE/4.2/kdepim/korganizer/views/agendaview/ -c934407
Line 261:
Line 261:
  The ''mergediff'' function shows the changes on the SVN properties in a nice way, because the normal output of ''svn diff'' is unreadable.   The ''mergediff'' function shows the changes on the SVN properties in a nice way, because the normal output of ''svn diff'' is unreadable.
    
− <code bash> + <syntaxhighlight lang="bash">
  function mergediff {     function mergediff {  
     svn diff -N | {           svn diff -N | {     
Line 297:
Line 297:
  The ''ssh-add'' is only needed when using svn+ssh, remove that is you use https or have found a better way to cache the key.   The ''ssh-add'' is only needed when using svn+ssh, remove that is you use https or have found a better way to cache the key.
    
− <code bash> + <syntaxhighlight lang="bash">
  function revlist_sort {   function revlist_sort {
     sed 's/,/\n/g' | sort      sed 's/,/\n/g' | sort



Winterz: in the examples, use "-S enterprise/kdepim" instead of "-S enterprise"
2010-12-17T15:01:16Z
in the examples, use "-S enterprise/kdepim" instead of "-S enterprise"

				
				
				
				
			
			← Older revision
			Revision as of 15:01, 17 December 2010
			
Line 72:
Line 72:
    
  When you have got multiple branches to merge from, you need to specify the target branch with the ''-S'' option. This is the case in the enterprise4 branch, which can merge from the enterprise35 branch or the KDE 4.2.x branch.   When you have got multiple branches to merge from, you need to specify the target branch with the ''-S'' option. This is the case in the enterprise4 branch, which can merge from the enterprise35 branch or the KDE 4.2.x branch.
−   svnmerge.py avail --log -b -S enterprise > avail.txt & +   svnmerge.py avail --log -b -S enterprise/kdepim > avail.txt &
    
  Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.   Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.
Line 81:
Line 81:
    
  Merging a commit is simple:   Merging a commit is simple:
−   svnmerge.py merge [-S enterprise] -r900000 +   svnmerge.py merge [-S enterprise/kdepim] -r900000
    
  Here, 900000 is a revision number you got from avail.txt, and the name after ''-S'' is the branch you want to merge from. You can omit ''-S'' if you only have a single branch with merge tracking.   Here, 900000 is a revision number you got from avail.txt, and the name after ''-S'' is the branch you want to merge from. You can omit ''-S'' if you only have a single branch with merge tracking.
Line 98:
Line 98:
    
  You can also merge multiple revisions at once. But use this with care, it will appear as a single commit, and therefore make ''svn annotate'' less useful. Only use this for closely related changes. For this, you can specify a revision list after ''-r'', like:   You can also merge multiple revisions at once. But use this with care, it will appear as a single commit, and therefore make ''svn annotate'' less useful. Only use this for closely related changes. For this, you can specify a revision list after ''-r'', like:
−   svnmerge.py merge [-S enterprise] -r900000,9000002,900004-900010 +   svnmerge.py merge [-S enterprise/kdepim] -r900000,9000002,900004-900010
    
  === Blocking commits ===   === Blocking commits ===
Line 105:
Line 105:
    
  Blocking commits has the same syntax as merging:   Blocking commits has the same syntax as merging:
−   svnmerge.py block [-S enterprise] -r900099,9000101,900110-900120 +   svnmerge.py block [-S enterprise/kdepim] -r900099,9000101,900110-900120
    
  Unlike merging, you should block all revisions you want to block in one go, so you don't create many unnecessary commits.   Unlike merging, you should block all revisions you want to block in one go, so you don't create many unnecessary commits.
Line 123:
Line 123:
    
  To fix this situation, you can mark a revision as merged by adding ''-M'' to the ''svnmerge.py merge'' command:   To fix this situation, you can mark a revision as merged by adding ''-M'' to the ''svnmerge.py merge'' command:
−   svnmerge.py merge -M [-S enterprise] -r900099,9000201,900210-900220 +   svnmerge.py merge -M [-S enterprise/kdepim] -r900099,9000201,900210-900220
    
  This command will add the given revisions to the list of merged commits in the list of the SVN properties.   This command will add the given revisions to the list of merged commits in the list of the SVN properties.
Line 209:
Line 209:
    
  First, you start by normally merging the revision, but not yet committing it.   First, you start by normally merging the revision, but not yet committing it.
−   svnmerge.py merge -S enterprise -r678876 +   svnmerge.py merge -S enterprise/kdepim -r678876
    
  You'll see some messages about skipped files, since we know they have been moved. In our example, it would be something like ''Skipped missing target libkcal/incidence.h''. Only the KOrganizer changes are not skipped.   You'll see some messages about skipped files, since we know they have been moved. In our example, it would be something like ''Skipped missing target libkcal/incidence.h''. Only the KOrganizer changes are not skipped.



TMG: /* Commit and merge policy for the KDEPIM branches */ adapt to reality
2010-08-02T21:30:24Z
‎Commit and merge policy for the KDEPIM branches:  adapt to reality

				
				
				
				
			
			← Older revision
			Revision as of 21:30, 2 August 2010
			
Line 140:
Line 140:
  == Commit and merge policy for the KDEPIM branches ==   == Commit and merge policy for the KDEPIM branches ==
    
− This section is only about the commits to the KDEPIM enterprise branches and for those who work on it. + This section is only about the commits to the KDEPIM branches and for those who work on it.
    
− There are 3 branches in total which need to be kept in sync: enterprise3, enterprise4 and trunk. + There are 4 branches in total which need to be kept in sync: enterprise3, enterprise4, trunk and the 4.5 branch.
    
  Merge tracking is available in the following directions:   Merge tracking is available in the following directions:
Line 149:
Line 149:
    enterprise3 -> trunk     enterprise3 -> trunk
    enterprise4 -> trunk     enterprise4 -> trunk
  +  4.5 -> trunk
  +  trunk -> 4.5
    
  The enterprise4 branch is discontinued, only Kleopatra-related commits happen there. Don't commit anything else to that branch.   The enterprise4 branch is discontinued, only Kleopatra-related commits happen there. Don't commit anything else to that branch.
Line 155:
Line 157:
  Manual merges and backports should be avoided because it doesn't update the merge tracking information in the SVN properties. This means that the merge guy later has to find out which commits were merged to which places, which usually involves digging through mail archives and websvn.kde.org, which is very time consuming.   Manual merges and backports should be avoided because it doesn't update the merge tracking information in the SVN properties. This means that the merge guy later has to find out which commits were merged to which places, which usually involves digging through mail archives and websvn.kde.org, which is very time consuming.
    
− === Ideal Lifecycle === + === Lifecycle of a commit ===
− The ideal lifecycle of a commit is the following: + 
− * The initial commit is done into the enterprise3 branch + 
− * The commit is merged with svnmerge.py from enterprise3 to trunk + 
− * The commit is manually backported from trunk into the 4.4 branch, if it is an important bugfix and does not contain string changes or new features. While manually backporting, the original svn log message (which includes the auto-generated svnmerge log messages) should be included, so that it is still known where the commit originated from. + 
    
− '''Try to stick to this ideal lifecycle, it makes the life of the merge guy much easier!''' + ==== trunk & 4.5 ====
− This ideal lifecycle also means that commits should '''never''' be started in trunk or the KDE 4.4 branch, since then you need to do manual merging, for example to the enterprise3 branch. One exception are commits that are only needed in the KDE 4 branches, but not in the enterprise3 branch. These commits can also start in trunk, there is a scenario somewhere below for that. + 
    
− One exception to this is when the commit is needed only in enterprise3 or only in the KDE4 branches (enterprise4, trunk, 4.4). + All bugfixes should go to the 4.5 branch first, and then be merged to trunk. This way we can provide a stable 4.5 branch that includes all bugfixes, which will become the first Akonadi-based PIM release. For details, see [http://thread.gmane.org/gmane.comp.kde.devel.pim/28222 this thread on the PIM mailinglist]. Please commit to the 4.5 branch first if possible.
    
− === Enterprise3-only lifecycle === + If you for some reason committed a bugfix to trunk first, it can be backported to the 4.5 branch with svnmerge.py. Since svnmerge.py is set up in both directions and since svnmerge.py detects bidirectional merges, the backported commit should not appear in the list of available commits in the ''4.5 -> trunk'' direction, so everything should work. If however you manually backported a bugfix from trunk to 4.5 without using svnmerge.py, then that commits needs to be marked as merged in the ''4.5 -> trunk'' direction.
− The lifecycle for a commit that is only needed in the enterprise3 branch is: + 
− * The initial commit is done into the enterprise3 branch + 
− * The commit is blocked with svnmerge.py in the enterprise3 -> trunk direction + 
    
− === KDE 4-only lifecycle === + New features should go to trunk and shouldn't be merged anywhere.
− The lifecycle for a commit that is only needed in the KDE 4 branches is: + 
− * The initial commit is done into trunk + 
− * The commit is manually backported from trunk into the 4.4 branch. See notes above. + 
    
− If you encounter a situation where no of the above 3 lifecycles would apply, please ask Thomas McGuire. + ==== enterprise3 ====
  +  
  + All commits to the enterprise3 branch should be merged into trunk. All commits should go to enterprise3 first.
  + A commit might need backporting to the KDE 4.5 branch, which should also be done with svnmerge.py (using trunk as the merge source).
  + The commit does not need to be merged to the enterprise4 branch.
  +  
  + ==== enterprise4 ====
  +  
  + Only Kleopatra-related commits should go into the enterprise4 branch at all.
  + All commits to the enterprise4 branch should be merged into trunk. All commits should go to enterprise4 first.
  + A commit might need backporting to the KDE 4.5 branch, which should also be done with svnmerge.py (using trunk as the merge source).
    
  == Problems & Solutions ==   == Problems & Solutions ==



TMG: /* Commit Keywords */ add info about MERGE keyword
2010-08-02T21:13:56Z
‎Commit Keywords:  add info about MERGE keyword

				
				
				
				
			
			← Older revision
			Revision as of 21:13, 2 August 2010
			
Line 136:
Line 136:
  * ''SVN_SILENT'': As written in the above sections, use this keyword when blocking or recording commits. This will cause the commit message to be filtered out for most users, avoiding unnecessary noise.   * ''SVN_SILENT'': As written in the above sections, use this keyword when blocking or recording commits. This will cause the commit message to be filtered out for most users, avoiding unnecessary noise.
  * ''SVN_MERGE'': Add this keyword to '''all''' commit messages that involve merging with svnmerge.py. With this keyword, the changes in the SVN properties are not added to the commit mail, which makes it possible to see the actual diff of the commit. This is very useful, as otherwise reviewing a merge from the enterprise35 to the enterprise4 branch would not be possible without launching an external diff viewer. Additionally, it lets users filter out merge commit notifications if they are not interested in those.   * ''SVN_MERGE'': Add this keyword to '''all''' commit messages that involve merging with svnmerge.py. With this keyword, the changes in the SVN properties are not added to the commit mail, which makes it possible to see the actual diff of the commit. This is very useful, as otherwise reviewing a merge from the enterprise35 to the enterprise4 branch would not be possible without launching an external diff viewer. Additionally, it lets users filter out merge commit notifications if they are not interested in those.
  + * ''MERGE'': This keyword is a reminder, and should contain a list of branches that the commit should be merged. This is purely informational. For example, a commit with the line ''MERGE: trunk, 4.5'' in the commit message would indicate that the commit should be merged to trunk and to the 4.5 branch. This is useful information in case that the person doing the merge is someone else than the person doing the initial commit. If there are no branches that the commit should be merged to, the keyword should be ''MERGE: None'', which simply indicates that the commit can be blocked by the person doing the merges with svnmerge.py.
    
  == Commit and merge policy for the KDEPIM branches ==   == Commit and merge policy for the KDEPIM branches ==



TMG: /* Commit and merge policy for the KDEPIM branches */ update for new policy
2010-01-22T13:06:05Z
‎Commit and merge policy for the KDEPIM branches:  update for new policy

				
				
				
				
			
			← Older revision
			Revision as of 13:06, 22 January 2010
			
Line 141:
Line 141:
  This section is only about the commits to the KDEPIM enterprise branches and for those who work on it.   This section is only about the commits to the KDEPIM enterprise branches and for those who work on it.
    
− There are 4 branches in total which need to be kept in sync: enterprise3, enterprise4, trunk and 4.2. + There are 3 branches in total which need to be kept in sync: enterprise3, enterprise4 and trunk.
    
  Merge tracking is available in the following directions:   Merge tracking is available in the following directions:
    
    (3.5 -> enterprise3)     (3.5 -> enterprise3)
−   enterprise3 -> enterprise4 +   enterprise3 -> trunk
    enterprise4 -> trunk     enterprise4 -> trunk
−  4.2 -> enterprise4 +  
  + The enterprise4 branch is discontinued, only Kleopatra-related commits happen there. Don't commit anything else to that branch.
    
  It is important to use svnmerge.py as much as possible. '''Avoid manual merging and crossporting!'''   It is important to use svnmerge.py as much as possible. '''Avoid manual merging and crossporting!'''
Line 156:
Line 157:
  The ideal lifecycle of a commit is the following:   The ideal lifecycle of a commit is the following:
  * The initial commit is done into the enterprise3 branch   * The initial commit is done into the enterprise3 branch
− * The commit is merged with svnmerge.py from enterprise3 to enterprise4 + * The commit is merged with svnmerge.py from enterprise3 to trunk
− * The commit is merged with svnmerge.py from enterprise4 to trunk + * The commit is manually backported from trunk into the 4.4 branch, if it is an important bugfix and does not contain string changes or new features. While manually backporting, the original svn log message (which includes the auto-generated svnmerge log messages) should be included, so that it is still known where the commit originated from.
− * The commit is manually backported from trunk into the 4.2 branch, if it is an important bugfix and does not contain string changes or new features. While manually backporting, the original svn log message (which includes the auto-generated svnmerge log messages) should be included, so that it is still known where the commit originated from. + 
− * If the commit is backported to KDE 4.2, it needs to be blocked with svnmerge.py in the 4.2 -> enterprise4 merge direction, since it is already in enterprise4 and therefore a cyclic merge. + 
    
  '''Try to stick to this ideal lifecycle, it makes the life of the merge guy much easier!'''   '''Try to stick to this ideal lifecycle, it makes the life of the merge guy much easier!'''
− This ideal lifecycle also means that commits should '''never''' be started in trunk or the KDE 4.2 branch, since then you need to do manual merging, for example to the enterprise3 branch. One exception are commits that are only needed in the KDE 4 branches, but not in the enterprise3 branch. These commits can also start in trunk, there is a scenario somewhere below for that. + This ideal lifecycle also means that commits should '''never''' be started in trunk or the KDE 4.4 branch, since then you need to do manual merging, for example to the enterprise3 branch. One exception are commits that are only needed in the KDE 4 branches, but not in the enterprise3 branch. These commits can also start in trunk, there is a scenario somewhere below for that.
    
− One exception to this is when the commit is needed only in enterprise3 or only in the KDE4 branches (enterprise4, trunk, 4.2). + One exception to this is when the commit is needed only in enterprise3 or only in the KDE4 branches (enterprise4, trunk, 4.4).
    
  === Enterprise3-only lifecycle ===   === Enterprise3-only lifecycle ===
  The lifecycle for a commit that is only needed in the enterprise3 branch is:   The lifecycle for a commit that is only needed in the enterprise3 branch is:
  * The initial commit is done into the enterprise3 branch   * The initial commit is done into the enterprise3 branch
− * The commit is blocked with svnmerge.py in the enterprise3 -> enterprise4 direction + * The commit is blocked with svnmerge.py in the enterprise3 -> trunk direction
    
  === KDE 4-only lifecycle ===   === KDE 4-only lifecycle ===
  The lifecycle for a commit that is only needed in the KDE 4 branches is:   The lifecycle for a commit that is only needed in the KDE 4 branches is:
− * The initial commit is done into the enterprise4 branch + * The initial commit is done into trunk
− * The commit is merged with svnmerge.py from enterprise4 to trunk + * The commit is manually backported from trunk into the 4.4 branch. See notes above.
− * The commit is manually backported from trunk into the 4.2 branch. See notes above. + 
− * If the commit is backported to KDE 4.2, it needs to be blocked with svnmerge.py in the 4.2 -> enterprise4 merge direction + 
−   + 
− === Alternative KDE 4-only lifecycle for bugfixes === + 
− Alternatively, the lifecycle for commits that are only needed in the KDE4 branches can also be like this, where the commit is started in trunk. This only applies for bugfixes. + 
− * The initial commit is done in trunk + 
− * The commit is manually backported from trunk into the 4.2 branch. See notes above. + 
− * The commit is merged with svnmerge.py from the 4.2 branch to enterprise4 + 
− * The commit is blocked with svnmerge.py in the enterprise4 -> trunk merge direction + 
−   + 
− === Lifecycle of features started in trunk (should be avoided) === + 
− If you prefer to develop features in trunk, refer to the following lifecycle. Developing in enterprise3 or enterprise4 first is usually better, since then you don't need to do manual merges. + 
− * Commit the initial feature to trunk. Note that it can't be backported to KDE 4.2, since it is a new feature. + 
− * Manual merge the feature to the enterprise4 branch. Please make sure that the log messages includes the original revision and the fact that the commit is a manual merge that originated from trunk. + 
− * With svnmerge, block the commit in the enterprise4 -> trunk direction, since it is a cyclic merge now. + 
− If you also want this new feature in enterprise3, do the following: + 
− * Manually merge the feature to the enterprise3 branch. Like above, use a detailed log message. + 
− * With svnmerge, block the commit in the enterprise3 -> enterprise4 direction, since it is a cyclic merge now. + 
    
  If you encounter a situation where no of the above 3 lifecycles would apply, please ask Thomas McGuire.   If you encounter a situation where no of the above 3 lifecycles would apply, please ask Thomas McGuire.



TMG: /* Merging Changes */ add info about SVN_MERGE and SVN_SILENT
2010-01-15T17:46:30Z
‎Merging Changes:  add info about SVN_MERGE and SVN_SILENT

				
				
				
				
			
			← Older revision
			Revision as of 17:46, 15 January 2010
			
Line 131:
Line 131:
  To check in your changes, type   To check in your changes, type
    svn ci -F svnmerge-commit-message.txt     svn ci -F svnmerge-commit-message.txt
  + 
  + === Commit Keywords ===
  + 
  + * ''SVN_SILENT'': As written in the above sections, use this keyword when blocking or recording commits. This will cause the commit message to be filtered out for most users, avoiding unnecessary noise.
  + * ''SVN_MERGE'': Add this keyword to '''all''' commit messages that involve merging with svnmerge.py. With this keyword, the changes in the SVN properties are not added to the commit mail, which makes it possible to see the actual diff of the commit. This is very useful, as otherwise reviewing a merge from the enterprise35 to the enterprise4 branch would not be possible without launching an external diff viewer. Additionally, it lets users filter out merge commit notifications if they are not interested in those.
    
  == Commit and merge policy for the KDEPIM branches ==   == Commit and merge policy for the KDEPIM branches ==



TMG: /* Getting the list of available merges */ fix link
2010-01-15T10:08:07Z
‎Getting the list of available merges:  fix link

				
				
				
				
			
			← Older revision
			Revision as of 10:08, 15 January 2010
			
Line 76:
Line 76:
  Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.   Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.
    
− Since getting the list can take really long, KDAB has a cron job that runs each night and generates the logs for all KDEPIM branches. You can find the logs [http://kdab.net/~thomas/ here]. If you have a branch that you like to include in the automatic generation of logs, ask me (Thomas McGuire) on IRC and I'll set it up for you. + Since getting the list can take really long, KDAB has a cron job that runs each night and generates the logs for all KDEPIM branches. You can find the logs [http://kdab.com/~thomas/avail here]. If you have a branch that you like to include in the automatic generation of logs, ask me (Thomas McGuire) on IRC and I'll set it up for you.
    
  === Merging commits ===   === Merging commits ===



TMG: /* Getting the list of available merges */ add info about cron job
2009-07-23T15:05:36Z
‎Getting the list of available merges:  add info about cron job

				
				
				
				
			
			← Older revision
			Revision as of 15:05, 23 July 2009
			
Line 75:
Line 75:
    
  Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.   Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.
  + 
  + Since getting the list can take really long, KDAB has a cron job that runs each night and generates the logs for all KDEPIM branches. You can find the logs [http://kdab.net/~thomas/ here]. If you have a branch that you like to include in the automatic generation of logs, ask me (Thomas McGuire) on IRC and I'll set it up for you.
    
  === Merging commits ===   === Merging commits ===



TMG: /* Conflicts on . */ clarify solution for conflicts
2009-06-03T12:51:12Z
‎Conflicts on .:  clarify solution for conflicts

				
				
				
				
			
			← Older revision
			Revision as of 12:51, 3 June 2009
			
Line 257:
Line 257:
    
  '''<u>NEVER</u> USE ''svn resolved .'' WHEN YOUR WORKING COPY IS OUTDATED, this will CORRUPT the merge information!!'''   '''<u>NEVER</u> USE ''svn resolved .'' WHEN YOUR WORKING COPY IS OUTDATED, this will CORRUPT the merge information!!'''
  + 
  + If you get a conflict on . that is not one of the above cases, '''revert''' your work with ''svn revert -R . *'' and do a ''svn update'', then try the svnmerge.py operation again. '''Do not attempt to fix the conflict on . manually, revert'''!
  + If you have important changes, save them with ''svn diff > somefile'' before reverting, and then afterwards cherry-pick those changes again.
    
  '''Afterwards, double-check that the SVN properties changes are indeed correct, by using the ''mergediff'' script from below. You do <u>not</u> want your SVN properties to become corrupted!'''   '''Afterwards, double-check that the SVN properties changes are indeed correct, by using the ''mergediff'' script from below. You do <u>not</u> want your SVN properties to become corrupted!'''

@@ Line 197: / Line 197: @@
 cd korganizer
 svn merge $SVNBASE/branches/KDE/4.2/kdepim/korganizer/views/agendaview/ -c934407
-</code>
+</syntaxhighlight>
 In this example, the exact directory where the moved files, in the branch to merge from, are, is specified (''korganizer/views/agendaview''). If this command is run in the directory (''korganizer'')  where the files are, in the branch to merge to, the changes will be applied.
@@ Line 275: / Line 275: @@
    rm /tmp/svnmerge.pre /tmp/svnmerge.post
+}
-</code>
+</syntaxhighlight>
 === automerge ===
@@ Line 328: / Line 328: @@
+}
-</code>
+</syntaxhighlight>
 == Further Reading ==

← Older revision		Revision as of 15:05, 23 July 2009
Line 75:		Line 75:

	Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.		Now, open avail.txt in a text editor. Your goal is now to deal with all revisions in this list, either by merging them, blocking them or marking them as already merged.
		+
		+	Since getting the list can take really long, KDAB has a cron job that runs each night and generates the logs for all KDEPIM branches. You can find the logs [http://kdab.net/~thomas/ here]. If you have a branch that you like to include in the automatic generation of logs, ask me (Thomas McGuire) on IRC and I'll set it up for you.

	=== Merging commits ===		=== Merging commits ===

← Older revision		Revision as of 12:51, 3 June 2009
Line 257:		Line 257:

	'''<u>NEVER</u> USE ''svn resolved .'' WHEN YOUR WORKING COPY IS OUTDATED, this will CORRUPT the merge information!!'''		'''<u>NEVER</u> USE ''svn resolved .'' WHEN YOUR WORKING COPY IS OUTDATED, this will CORRUPT the merge information!!'''
		+
		+	If you get a conflict on . that is not one of the above cases, '''revert''' your work with ''svn revert -R . *'' and do a ''svn update'', then try the svnmerge.py operation again. '''Do not attempt to fix the conflict on . manually, revert'''!
		+	If you have important changes, save them with ''svn diff > somefile'' before reverting, and then afterwards cherry-pick those changes again.

	'''Afterwards, double-check that the SVN properties changes are indeed correct, by using the ''mergediff'' script from below. You do <u>not</u> want your SVN properties to become corrupted!'''		'''Afterwards, double-check that the SVN properties changes are indeed correct, by using the ''mergediff'' script from below. You do <u>not</u> want your SVN properties to become corrupted!'''