SVN merging - philosophy

We are thinking over restricting merge points in our subversion project.

The idea behind is to keep merging more tidy, as we are afraid that with significant number of developers new to svn, we might get cobweb of different merge points.

We afraid of all different side effects, so such restrictions will help us to have everything in place.

As a basic concept we decided to a开发者_如何学Pythonllow branching only on root and merge only on the top of the branch. This make all nice. But....

But as some of developer groups use 10% on overall trunk, it seems reasonable to allow them to branch only on.

Then the fun starts. If we give them freewill then merging could occurs everywhere. I am really afraid of that. That is how I came to the issue:-)

How would you see the clean way of setting the things up?

Thanks!

Unless you want to restrict commit access to a particular branch, there's no easy way of doing this in Subversion.

First of all, it's common to just want to limit your merges to a small sub-set of files. If you only allow merges at the project level, I can't selectively merge when needed.

The other problem is that svnlook doesn't tell you why a file was changed. Even if you could prevent commits if certain files have svn:merge-info on them, users could easily use the --ignore-ancestery parameter and not only do the merge, but not even record it was done which will mess you up even worse since you don't have information that the merge was even done. Remember that if you prevent a user from doing what they feel they need to do, they'll find ways around your restriction.

The best thing to do is to trust your developers, and have them trained how and why they should do merges in Subversion.

Remember that you are an all seeing God when it comes to Subversion. There is nothing hidden from your all knowing presence. If a developer does do a wacky merge, you'll know via the "svn log". That power keeps developers in line. This is especially true if you get the tech leads to buy in on why you need to merge in a logical and coherent manor. After all, it's the development teams that suffer if merging goes awry.