Is this the correct step-by-step and organization for creating an SVN repo with multiple projects and vendors?

Question

I've read quite a bit of the Red Bean Software SVN Book, and some of the questions here on SO, but I want to make sure I'm going about this in the right way the first time around step-by-step before I begin using it. Is this correct?

1. Install SVN.

2. Create SVN repository at /usr/local/svn. Directory structure looks like this:

   -- conf
   -- db
   -- format
   -- hooks
   -- locks
   -- README.txt
   

3. Create folders through command line for repository organization (including projects and vendors).

   -- conf
   -- db
   -- format
   -- hooks
   -- locks
   -- projects
      -- project_name
         -- vendor
         -- trunk
         -- branches
         -- tags
      -- project_name
         -- vendor
         -- trunk
         -- branches
         -- tags
   -- README.txt
   

4. Checkout vendor code into vendor folder under the correct project name.

5. Export vendor code into trunk under the correct project name (no merge necessary, as I have no project trunk files yet).
6. Create users/permissions in /svnroot/conf/passwd and /svnroot/conf/svnserve.conf.
7. Make sure that svnserve is running, and on my local SVN client (TortoiseSVN), checkout the trunk for the project that I need.

I don't need to serve this up by public URL, so I'm not configuring for Apache. The server is not in our network, but is a dedicated CentOS box we rent. Thanks for any thoughts and advice.

EDIT:

I guess I'm confused because I don't have code or a project to begin with, so I am starting fresh from the vendor's code. Do I need to create a directory structure somewhere on the server that includes my project_name w/ vendor, trunk, branches and tags subfolders, import that into my repo, and then import the code from the vendor into the vendor folder? The idea is that I can get updates from the vendor, and then merge those updates with any changes I made to my trunk.

Answer 1

Create folders through command line for repository organization (including projects and vendors).

Do you mean creating the repository structure by making directories inside the subversion intallation directory? That's very wrong.

You have to create the necessary folders via the svn mkdir command and not via filesystem.

In /usr/local/svn you have the physical implementation of the Subversion repository, and you must access it only via a client, and never touch it "by hand".

For example, using the file:// URL scheme

svn mkdir file:///usr/local/svn/projects -m "Parent dir for projects created"

Answer 2

You seem to have mostly the right idea, but your terminology is a bit wrong. That will really confuse the SVN people, since you're using words that have specific meanings in the context of SVN. To expand on what Davide said:

2) create your repository by doing something like svnadmin create /usr/local/svn.

3) create your folders. You don't need (or want) the parts of your list that aren't below projects/. Those other directories are what SVN uses to keep track of revisions, they're not actually in the repository. If you create a directory hierarchy somewhere on your system that contains the project_name/ subtree, you can then run svn import on it as many times as you want, once for each project (giving a different name for the destination each time). That will create your directory structure.

4) Instead of "checkout", I think you mean either "import" or "checkin" (usually called "commit" in SVN parlance, but "checkin" will be understood). Importing will add the vendor files to the repository. Checkout means "create a local copy of this versioned directory for me to work with" known as a Working Copy. Every developer on your team should have their own working copy. After a developer makes changes to their working copy, they then svn commit them which sends the changes to the repository. The other developers on the team will run svn update to get those changes from the repository into their own working copies.

5) I haven't read the SVN book lately, but I think it instructs you to copy the version of the vendor branch into the trunk, not export it. Exporting in SVN terms means to un-version the directory tree, which is clearly not what you want.

You may find things easier if you do steps 6 and 7 right after step 2, since then you can use the svn:// protocol to access your repository for the remaining steps instead of file:// as suggested by Davide, which only works on the local machine.