Trevor wrote: "Can you tell us exactly what you are trying to do when you
come across these
problems. If you are modifying the structure of directories/renaming files
you need to make sure to do it using the tools. Either by using tortoise to
rename them, or having subclipse rename them. This way they will know what
the other is doing. If you are just moving files using file system
commands, then neither will know what's going on."
The thing we are doing "wrong" seems to be using an external tool like
Windows Explorer to delete a folder that is under source control and then
replace it.
I will concede that source control typically means the files live in the
working area and are not frequently transplanted.
The disturbing thing is this: by a series of very normal file management
actions, it is foolishly easy to put subversion into a state in which it
simply cannot offer adequate means to fight your way out of.
To correct our problem, we delete everything and then very carefully rebuild
it all, stopping to let SVN know what's going on at every microstep. This
feels like it is us who serve SVN and not the other way around, but a zero
cost, I guess we can't complain.
What I wish SVN could do is figure things out when:
1. We delete a folder.
2. We replace the folder with a new folder of the same name. Some of the
files within it match what was there before, and some don't.
3. We tell SVN to do a Clean Up or Update or some simple command
4. We are able to commit the files
How hard is that? Doesn't it seem like a robust source management tool
would handle this in stride?
Received on Wed Jul 26 19:38:58 2006