3 ms·

Really it's "don't rename files if you use branches at all" (because renaming a file in trunk will cause merges of outstanding branches to fail)

• wcoenen 16y ago
  I wouldn't say "fail". You'll just get a tree conflict where SVN complains that it can't merge changes because a file no longer exists. In TortoiseSVN such a conflict is trivial to resolve, because the tree conflict dialog gives the option to apply the changes to the renamed file instead: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-conflicts.html#tsvn-dug-conflicts-tree-1 http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-...
  • prodigal_erik 16y ago
    The article claimed that "svn merge --reintegrate" did not complain about a conflict, just quietly gave the wrong result. I'm the designated svnmerge.py entrail reader at work, and I've seen that make even more severe mistakes. (They keep saying our git repo will be ready Real Soon Now[tm]. So looking forward to that.)
    • wcoenen 16y ago
      The article demonstrated a silent bug in a specific use case: merging a rename for a file which was modified locally. I was responding to the generalization "don't rename files if you use branches at all". Things are not that bad. As I explained above, merging a change to a file which was renamed locally works fine: it triggers a tree conflict which is easy to resolve. svnmerge.py was deprecated by the introduction of merge tracking in subversion 1.5, so I'm not sure why you are still dealing with that. You can migrate with svnmerge-migrate-history.py