I know this isn't the BEST practice, but every once in a while when I'm merging up a huge batch up changes with the trunk (and I know my branch is current), I will simply delete the contents of the trunk and then copy the contents of my branch up, so that I don't have to deal with resolving conflicts for an hour. The problem is that I seem to lose the entire history of commit messages for each file. My branch still has the correct history of commit messages... how can I merge them up?
+1
A:
Can't you merge your branch into the trunk. It sounds like you are literally copying the files, hence creating a new file that needs to be tracked and losing your history.
Steve Robillard
2010-04-26 07:53:06
+5
A:
You urgently ought to go and read up on Branching and Merging. What you're doing is working against SVN, instead of using it.
I wouldn't want to have to use that repository.
What is the best practice for a situation like this?
You merge the changes from the trunk into the branch as often as possible. This is also the last thing you do before you reintegrate the branch's changes into the trunk.
sbi
2010-04-26 08:00:57
I'm new to subversion, so I'm still learning best practices. I tried emptying the trunk and then merging in my branch, but to no avail. None of the files seemed to transfer. I realize the *correct* way is to merge my branch with the trunk, but like I said, there were a large number of changes that would have been incredibly difficult to resolve. What is the best practice for a situation like this? (other than the obvious: commit more often)
Falcor
2010-04-29 04:03:40
@Falcor: I have answered your question in my answer.
sbi
2010-04-29 05:26:16
A:
Mercurial and Git make merging easier (as described here, here and here). It doesn't sound like you're getting much value from your repository the way you're using it so you might as well consider switching without as much hassle merging as you have now.
Oh, and erasing all of the contents of the trunk is a bad idea. No amount of "I know, but..." makes it better.
Tomislav Nakic-Alfirevic
2010-04-26 08:59:13
Why is it that every other time someone asks a question about SVN some DVCS advocates come along and suggest switching to git or hg? Are you guys watching the `svn` tag so you can preach the unworthy?
sbi
2010-04-26 09:30:39
Nope, I'd have nothing to do with that. The problem Falcor has occurs because he finds merging using svn difficult. Because that's one of the key differences between svn and hg, I suggested a tool which doesn't make merge (as) difficult and would so allow him to focus on what he wants to get done.Preaching is something I haven't yet learned to avoid doing when talking about issues like the environment. ;) Version control in other people's shops is not one such issue.
Tomislav Nakic-Alfirevic
2010-04-26 11:32:04
It seems to me the OP has a fear of merging. This may be due to the fact that merging in SVN is difficult, or it may simply be that he *thinks* it is difficult. In fact, he's been merging from the trunk to his branch, but not from his branch to the trunk. I imagine that after reading sbi's link, he will find that SVN suits him just fine.
MatrixFrog
2010-04-26 17:11:26
"Trunk" is just a name for a default branch, nothing special about it to make merging from one to another easier than merging from the other to the first. I also thought SBI's answer was of value, which is why I upvoted it.
Tomislav Nakic-Alfirevic
2010-04-26 20:58:49
@Tomislav: Indeed, "trunk" is. basically, just another branch, so merging shouldn't be a principle problem. I suppose Falcor hasn't read about how to reintegrate a branch. (Oh, and FTR, it wasn't me who down-voted your answer.)
sbi
2010-04-27 09:51:47