I’ve started using svnmerge.
Merge is one of the problems we’re presently facing in our project. The project is massively parallel, and we’ve stablished a repository layout based upon some form of ‘stability ladder’.
Every team is responsible of promoting its products to a state in which they can be used by the other teams. They will promote from their development branch to the stable branch, so the rest ot the teams can make the dependency cross-testing.
Once the preceptive testing is done, the integration team will eventually promote those stable products into the release branch.
The main problem; we don’t have enough merge-savvy people. Merge is mostly a matter of discipline, I think, but users (well, they’re developers, but users of the SCM system) tend to expect an oversimplified filesystem, without even considering the whole scope of the problem being solved.
Software Configuration Management is not a trivial task, and merging is not an automagic silver-bullet. You must prove yourself insightful when looking at the code; study, merge, and resolve the conflicts if present.
You must also trust the procedure; conflicts are not failures, nor they are bugs. Conflicts are the natural result of concurrent development. Accept it, and solve them.
You must accept this, and you must learn:
you don’t commit files. You commit changes.
you don’t need to lock the file.
the earlier you update, the better.
- 1.
The working copy structure is weak. It’s too easy get it mangled, sometimes with aparently innocent actions.
- 2.
The error messages are poor. The only tip you’ll get is probably 'try running svn cleanup’, when it’s something that could possibly run automatically. On the other hand, you’ll not be advised 'why don’t you use –ignore-ancestry?’, though you probably need it when some 'doesn’t match a revision’ or 'missing target’ appear when merging.
- 3.