Rearranging project after SVN checkout

Question

This is probably SVN 101, but I have to ask:

I'm working on a project that has kind of a lame directory structure. In order to get it building and running in my favorite IDE, after I check the project out, I copy the whole project to a different directory and move things around to my (and my IDE's) liking.

So my basic question is this: can I safely edit/update/merge a file that is in a different directory strcuture than the repository's directory structure?

E.g., if I check out /home/me/dev/proj/index.jsp and then copy it (and its .svn metadata) to /home/me/dev/better-proj/web/index.jsp, the fact that index.jsp resides in a different directory should be okay with regard to its SVN status, right? Wrong? Or am I just asking for trouble?

Answer 1

I misunderstood your question. I thought you were looking for something like the SVN move command. (see these questions)

But that is apparently not what you are looking for.

I think you are asking for trouble with your proposed workflow. That is really not a good idea. Why don;t you just move the work items within svn?

Answer 2

So you work with the project in a different structure than others on your team? I'm not sure how that works honestly. I would talk to everyone involved, and use svn:move to get all the files with history in the places you all can agree on.

Answer 3

You're asking for trouble. Lots of trouble. If you attempt to update the root, you'll get complete insanity as a result (lots of obstructions, "restored" files, etc). Also, how are you copying the metadata of an individual file? SVN metadata lives in a .svn folder that is per-directory. You might be able to update and commit individual directories that haven't been changed (i.e. the directory itself has been moved or renamed, but all of its children are exactly as in the repo). Then again, you might not. It's dangerous.

You should either customize your IDE to match the way the project is intended to be used/built, or rearrange the project to match how it needs to used/built. In the latter case, you'll want to investigate the svn move subcommand (i.e. svn help move). A GUI for SVN would probably also be helpful, such as TortoiseSVN (for windows) if you're going to be doing a lot of rearranging.

Answer 4

You will encounter problems with this approach if you try to put a versioned directory inside a versioned directory that is not its parent. Other than that, you shouldn't run into anything other than the paperwork headaches associated with a disjoint working copy.

Is there a reason you can't use svn move to reorganize the project in the repository? you won't lose any history that way, and you will make your life much easier.

Answer 5

If the destination is still within your working copy, use svn move (documentation). Either way, you don't ever want to manipulate the .svn metadata yourself as this will lead to conflicts and general headache.

If the destination is the working copy of another repository, you'll want to do an svn export (documentation) on the source repo followed by svn add (documentation) on the destination repo.

Also worth reading: Subversion Basic Work Cycle