Merge conflicts relating to files on disk - an old enemy of mine, and I'm sure, many others. Particularly situations such as creating / deleting modules, leaving behind folders in the java folder etc. can cause nasty conflicts which really only seem to be fixed by downloading a new copy from the teamserver and working around to prevent losing your changes somehow. I am wondering what Mendix' outlook is on this facet of working with Mendix. Is the current way "the" way? Can conflicts like these not be prevented? Or perhaps ignored, since really, there's no harm in either having or not having a folder that belonged to a deleted module? Could Mendix provide perhaps a built in SVN browser? Or an override mechanism? Workarounds and solutions exist, sure. But nobody really likes seeing that dreaded pop-up, especially when you have 30 changes lurking in the background...
I agree with the both of you, this can be annoying sometimes. But a few rules of thumb avoid this issue to happen in general in my experience:
Never change the casing of the name of a java action. SVN+windows just cannot handle changing the case in filenames. If you need to do so, first delete the file/action, commit, create again with the right name, commit
Only import modules when you have no uncommitted changes. If something goes wrong, you can just checkout again, and it is a best practice anyway.
If you create a java action, first deploy for eclipse, then commit. If you do this in the wrong order, in older modeler versions, this would create conflicts, because the code of the same java action then gets generated by other users of the project as well, which will be either accidentally checked in, or cause a conflict during update, because somebody else checked in. I think newer modeler versions always automatically generate the actions before a commit.
True, we also have sometimes the dreaded conflicts in the java folder that seem pointless (empty directories etc.) and are hard to repair with all the users of the teamserver (I would repair and commit, but then somebody else gets the conflict and does a repair and then the next person gets the conflict). Our sollution is to send a mail to all the developers on this teamserver with the steps to take in svn. Only if all the developers do the exact same steps it seems that this errors wil be resolved by all.
That said, it does not happen very often (about 4 times per year but we do not use java code very much). So yes, if this would disappear I would be happy. But I still now of the days without the teamserver and these were much worse :)