We finally switched to subversion because in theory, it was better than what we were using (MKS), turns out subversion is quite awful in its own right.
For safe/reliable/efficient merging, in general, you need merge tracking.
Sadly, this isn't in the current version of subversion. Don't believe me, read the manual.
I'll quote the relevant bits.
Merging changes sounds simple enough, but in practice it can become a headache. The problem is that if you repeatedly merge changes from one branch to another, you might accidentally merge the same change twice. When this happens, sometimes things will work fine. When patching a file, Subversion typically notices if the file already has the change, and does nothing. But if the already-existing change has been modified in any way, you'll get a conflict.Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible.Unfortunately, Subversion is not such a system. Like CVS, Subversion does not yet record any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running svn merge, or from just hand-editing the files.
Yes, there is svnmerge. But it isn't perfect. It relies on the svn merge to do the real work. Unfortunately I haven't figured out a way to pass useful parameters like ignore spaces etc to it from the svnmerge proxy.
Anyways, yes, with work you can do it. But that is assuming everyone on your branch is willing to use svnmerge, or can. Oddball crashes on windows systems has scared the windows users away, so they merge track manually with tortoisesvn.
That said, my favorite feature of svn is the 'switch' command. In a largish project with a fair number of sub projects, it's nice to be able to branch just a subproject via svn mkdir and cp, the switch to the branched version in place.
Doing this kinda freaks out IntelliJ (at least on my MacBook Pro it does), so branching and switching is done with my editor closed.
I don't think Perforce has the ability to switch out a branch/tree from a single command, but it should.
With the switch command, we are one step closer to ripping out maven. Heh, I wish...
Actually, think about it for a second. One of the points of maven is to manage the version dependencies between libraries. This is what tags and branches are.
It would be nice to have a tool on top of mvn or perforce that used tags/branches, instead of 'deployed' jars and pom files. This way a simple ant script could be used to make world, instead of spending your days debugging maven plugins and pom files.
Leave a comment