SVN - Merging the Same Change

Sometimes, I seem to be getting a conflict when trying to commit a change to SVN, if someone else has already committed the same exactly change before me.

So, I create a little repo with a single Java file in it and branched it.  Let's assume the file is like this:

1:    Line1  
2:    Line2  
3:    Line3  
4:    xxx NIE yyy  
5:    Line5  
6:    Line6  
7:    Line7  

On the trunk, I have changed NIE to TAK and Line2 to XXX and committed the change.  On the the branch, I have changed NIE to TAK and Line6 to YYY and committed the change as well.  When I merged the changes in trunk into the working copy of the branch, I've got only a change of Line2 brought in.

So, the conclusion is, that an identical change is merged by SVN smoothly, even if other non-matching changes were found nearby.  Or possibly, it's not SVN but the merge tool, which in my case was the Tortoise SVN built in merge tool.

SVN Externals - Create and Edit in Tortoise SVN Client

SVN let's you create links inside the repository.  For example, if with your project A you always need a module B, which is in another part of the SVN repo, you may want to create a svn:external to B in A.

Steps:

• open the project A in repo browser
• right-click on the project and select properties
• click New->Externals to create a new one or select it and click Edit to modify an existing one
• point the external to B and carefully consider whether you want to point it to the HEAD or to a specific version; the latter will make your project A always build regardless of what happens with project B

The same dialogs you can access from windows menu of folder A of the working copy, from the Subversion tab. Once you're there, click on Properties.

Project Versioning and Release - Best Practice

• A new project starts usually as version 1.0.0.0-SNAPSHOT. Three number versions (1.0.0) are also used but, for example, ServiceMix OSGi server requires three dots.
• A new feature/fix is frequently developed on the trunk and committed there when ready for release.
• Release. It is usually done on the trunk (does it have to be? what if someone commits changes in the middle of a release?). It is all done by maven release plugin, (more datails here). Is done in two steps: mvn release:prepare i mvn release:perform. What maven does during a release:
• up the version by 1 (often on the last numbered position: 1.0.0.1)
• build, maven-release and deploy to organization's repository if any
• tag it in SCM
• up the version number on the trunk (it will become 1.0.0.1-SNAPSHOT)

Notes:

• On the trunk, we have always -SNAPSHOT versions
• Each release has a tag
• If the maven release plugin fails, it usually leaves the pom.xml messed up on the trunk.  Make sure to fix the version and scm tags. 
• Alternatively,  a new feature/bug fix can be developed on a branch.  In this case, the branch needs to be merged to the trunk, when feature/bug fix is ready. I guess, this merge should happen before the release.
• In multi-module projects,  if you want to give the same new version to all modules, add set the option autoVersionSubmodules to true (in parent pom?  where?). Otherwise, you'll be asked for the new version for each module.