I'm totally new to CVCS (SVN specifically). I find that most resources focus very strongly on the command-line commands (irrelevant; we use Windows Explorer + TortoiseSVN) and about structure (e.g. projects inside our outside TTB, etc). Here's a thing about merging I'm not sure of:Based on my sandbox testing, I got the understanding that merging should be done sort-of backwards? I first thought that merging meant going from the branch into the trunk, but it now seems to me that I should actually merge the trunk into my branch, fix conflicts there, and only then commit my branch into trunk?Let's say I'm responsible for merging a branch into the mainline, and everybody has committed their local changes into that branch. I now switch my working copy to the branch and merge the trunk into my working copy in order to resolve any conflicts locally and tidy things up. When complete, I commit my working copy into the trunk (there should be none or hardly any conflicts in this step).This is basically also what one needs to do when committing changes from one's working copy into the branch. Right? Wrong? Am I missing some steps? It seems complicated but makes sense.Let's not argue about how merging in SVN is harder than in DVCS's because that's not something I can change.Also, I'm not asking about the specific command-line actions because we're using TortoiseSVN.
Proper sequence of actions for merging using SVN?
programming practices;version control;svn;branching;merging
Yes, that is a best practice for how SVN is designed.  You have your branch, you merge the trunk into your branch, because there are always issues to deal with (it is easier if you periodically do this while working on your branch), and when it's good you merge it back into the trunk. At this point there shouldn't be any conflicts unless someone else has come and checked in updates in between.It does seem complicated but after doing it a few times it becomes easier.