Its very disputed indeed, however I have experienced that some practices in using SVN results in less conflicts than others.
The practices which yield the best results depend highly on the method in the organization and the general practices of the team.
Every opinion I share in this post is therefore based on the notion that it works in the company I work for and the current team I am working in as well as the codebase we are working on.
During a development cycle I will probably end up updating every hour or so. This is not a conscious activity, but more of a habit as it has proven to allow me to experience long periods of no conflicts or merges.
I should perhaps point out that I work as an architect on a system with about 10 developers and a codebase of apr. 3500 classes divided into vast amounts of modules and libraries. Our SVN is configured with positive assertiveness so we let the SVN assume that conflicts will not appear and that if they do, merges will be possible. This works well for us.
The single most important rule of SVN engagement on my slate is the “Update Prior Commit” dictating that I always run an update before I execute a commit. SVN will warn you anyways, but it gives me a second to think about what I am committing which I have think gives me some percentages in regards to preventing SVN errors.
I would say that anyone in our organization should commit at least every day and should update at least a couple of times per day. This is due to the very lively nature of our current codebase which kinda means that we don’t have any very stable areas in the codebase except for our core classes.
If the task at hand is too big to be committed every day, it should be branched and hence committed every day. This practice has a couple of times proven to work as an invaluable backup when disks have malfunctioned or users have caused Error-40’s (In case you don’t know I what I am referring to with “Error-40”, ask a computer-saavy Dane – (s)he will tell you 🙂 )
(to be continued)