Tortoise SVN - Case sensitivity issue under Windows - Problem Merging_问答_开发者

I have been working in a branch for a couple months and am now trying to merge the trunk into the branch, before finally merging my branch into the trunk.

After successfully merging a few revisions, SVN threw an error about the "bin" folder b开发者_如何学Goeing locked. When I created my branch, the folder was called "Bin", but at this particular revision that threw the error, another developer inadvertently committed a duplicate directory called "bin". During the merge, SVN attempted to bring down the new "bin", but Windows balked, throwing the lock error.

My question is how to deal with this? Although the project in question went through many changes, including deleting the Bin, deleting the bin, and eventually adding the Bin back, I have to replay all of those actions when I am merging revision-by-revision from the trunk to my branch. How do I get past the error when it occurred in the past? Do I go into Repo Browser and delete the duplicate "bin" folder in the old revision? This is very frustrating because it wasn't an error when the other developer checked the duplicate directory in, but it causes an error when trying to merge/update that revision to my working copy.

Also, am I supposed to be committing after merging each revision into my branch? Or am I safe to keep merging and commit my branch only at the end?

Thanks for any help you can provide.

You don't need to merge revision by revision. You can merge all changes of a branch/the trunk into another branch/the trunk at once.

If this doesn't cure the renaming woes (been there myself), I know of two ways to solve the issue:

Use Linux. Seriously. Unix file systems are case-sensitive, so you can sort it out there. If you don't know Linux, just boot into an Ubuntu installation in a virtual machine and use that to do your merging.
Manually delete the offending folder from the target branch, then svn copy the new one into its place. Unfortunately, on Windows, you cannot do this in one step.

Still, on Windows you will get into trouble when you try to update a working copy that has a Bin folder and the update needs to delete that and create a bin folder at the same time. You can solve this by either manually deleting the offending folder in the working copy (no svn delete!) and then letting svn up restore it, or by just trashing that working copy and checkout anew. If you do #2 from above, you might also be able to first update to the intermediate version (where the old folder was deleted), and then to the head.

Edit: I only now saw your additional question:

am I supposed to be committing after merging each revision into my branch? Or am I safe to keep merging and commit my branch only at the end?

As a rule of thumb: Whenever you perform an operation in your working copy, you need to later commit this for it to appear in the repository. When you perform an operation on the repository, it automatically creates a new repository version and you don't need to checkin. (You should then provide a checkin comment with the command.) That's especially worth knowing for commends (like svn copy) that can use either a working copy or a repository as a target.

the idea of merging is to commit only at the end - once you're happy with the merge result. You shoull review the merge operation as there's always a case where the computer gets confused, you don't want to commit those confusions in!

Ok, so to fix the problem here.. I think I'd suggest trying to merge all your changes up to the offending revision, then merging the bad revision by itself and seeing if that helps. When you get to the tree-conflict error, you can fix things up manually, resolve the conflict and then merge the remaining revisions.

An alternative approach might be to create a new branch from trunk at the same point you started your branch, then checkout the trunk's HEAD revision and commit, then merge that (single revision) to your branch so you'll get all the changes without the intermediate problem. Then you can update your mergeinfo property to tell your branch that you've merged all the revisions from trunk already so it won't try to merge them next time. A bit of a fudge, but it might save you some headache.

Generally though, problems like this are solved by understanding how svn merge works, tree-conflicts are a nuisance but once you've got them, they're easy to fix. What you describe does sound like a tree-conflict, but let us know if you're getting a different error.