I have four projects that are managed by SVN. Two have the most recent release to production in the branch and two have the most recent releases in the trunk. Is this bad practice? Should all releases be in the trunk?
Do developers use change logs or tags to label revisions that were released to production? Is a change log a concept of SVN/source control or is it simply a Word document contained in the trunk?
I am a sole developer at the moment but this could change in the future.
There is no short answer to your question.
First, by release, you mean svn revision or a stable state of project that you can deliver to consummer /user ?
Conceptually the most recent deliverable-release should be copied into tags and should also be somewhere on the trunk, you can have various revisions above it (depending wether your policy permits you to commit unstable-work on trunk).
There is several flow models, all have its advantage and drawback.
Flow 1- Every developper synchronize and commit to trunk. Flow 2- Create new branch for each new feature, or bug solving and reintegrate merge when solved. Flow 3- Each developper have its own branche(s) and syncrhonize with trunk and someone pick merge individual changes on trunk test and commit. Flow 4- Flow 2, but a single developper take care of the trunk.
In the first model,branch principle are rarelly use. This is the simplest flow but it have limitations in term of parallel development. If you are single developper you can use it and then switch to other policy.
In flow 2-4 you have on trunk/ the last stable version, but the more advanced version in development is on some branch or spread among branches.
Its not a complete analysis, but hope it helps your reflection.
