The problem that you are running into is, when you are deleting folders, you
are deleting the .svn folders underneath them. Without the .svn folders
subversion doesn't know what's going on anymore. You can change the
contents of the files extremely easily, however if you want to keep a
directory under version control then you need to keep the .svn directory
intact. If you want to change the structure of what's under source control,
then you need to tell subversion what's going on.
You could write a script that would do what you want to do, where it would
have a directory that is actually under version control. But then it would
export the directory into a second directory, there you could delete it,
modify it, what ever. Then run another script that would copy everything
back into the original working copy that you had checked out. and it would
add/delete any files from subversion that you wanted.
This is possible, but it would take a little work to do in your environment.
-Trevor
On 7/26/06, Bill Ewing <bewing@nexusbio.com> wrote:
>
> 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 20:09:11 2006