Please use Reply All so your replies go to the list too, not just to me. This way others can participate in and benefit from the discussion.
On Apr 5, 2011, at 10:57, p...@pcrt.us wrote: > Yes, I see the great flexibility. But there are no examples in the book of > the svnadmin commands to do it. The command I used, from appendix A, set up > several directories underneath repos, with no intevening project directories. > I hesitate to change the paths to those directories by brute force and have > no idea how to use svnadmin to do all the reshuffeling. I would rather start > over, but again, I could find no example of an svn create that puts in the > project directories. I apologize if this all sounds dumb. "svnadmin create" is only used to create the repository (the filesystem, the database). What you do with the repository (filesystem, database) after that (i.e. what directories and files you put in it) is up to you, and you'll be using the svn command, not the svnadmin command, to do so. On Apr 5, 2011, at 11:47, p...@pcrt.us wrote: > Alright, I think I have it now. There is no one svnadmin create statement > that can set up three projects. But I can do them one at a time it seems. I > did this > > #mkdir /usr/svn/repos/project1 > # svnadmin create /usr/svn/repos/project1 > #mkdir /usr/ mkdir /usr/svn/repos/project2 > # svnadmin create /usr/svn/repos/project2 > # mkdir /usr/svn/repos/project3 > # svnadmin create /usr/svn/repos/project3 > > Now each of the project directories has a tree of directories labled conf db > format hooks locks and a README.txt > > Thanks for your help. You've used multiple svnadmin create commands, which means you now have several independent repositories; based on the names you've given them, I suspect you intend to use each repository to contain a single project. That's fine. By the way, you don't need to "mkdir" before you "svnadmin create"; svnadmin will create the directory for you. You can now create the trunk, branches and tags directories in each project's repository: svn mkdir file:///usr/svn/repos/project1/trunk svn mkdir file:///usr/svn/repos/project1/branches svn mkdir file:///usr/svn/repos/project1/tags svn mkdir file:///usr/svn/repos/project2/trunk svn mkdir file:///usr/svn/repos/project2/branches svn mkdir file:///usr/svn/repos/project2/tags svn mkdir file:///usr/svn/repos/project3/trunk svn mkdir file:///usr/svn/repos/project3/branches svn mkdir file:///usr/svn/repos/project3/tags Alternately, you could have decided to create a single repository to hold all your projects: svnadmin create /usr/svn/myrepository Then you would create directories for each project inside it, along with the trunk / branches / tags directories: svn mkdir file:///usr/svn/myrepository/project1 svn mkdir file:///usr/svn/myrepository/project1/trunk svn mkdir file:///usr/svn/myrepository/project1/branches svn mkdir file:///usr/svn/myrepository/project1/tags svn mkdir file:///usr/svn/myrepository/project2 svn mkdir file:///usr/svn/myrepository/project2/trunk svn mkdir file:///usr/svn/myrepository/project2/branches svn mkdir file:///usr/svn/myrepository/project2/tags svn mkdir file:///usr/svn/myrepository/project3 svn mkdir file:///usr/svn/myrepository/project3/trunk svn mkdir file:///usr/svn/myrepository/project3/branches svn mkdir file:///usr/svn/myrepository/project3/tags Or, if the versions of each project are the same and the projects are highly interrelated, then perhaps this structure is more desirable: svn mkdir file:///usr/svn/myrepository/trunk svn mkdir file:///usr/svn/myrepository/trunk/project1 svn mkdir file:///usr/svn/myrepository/trunk/project2 svn mkdir file:///usr/svn/myrepository/trunk/project3 svn mkdir file:///usr/svn/myrepository/branches svn mkdir file:///usr/svn/myrepository/tags In each case, instead of using a file:// URL to the repository, of course you should really be setting up svnserve and/or httpd to access the repository(ies), and you should then use the corresponding svn:// or http:// URL(s) you've chosen. You'll have to decide whether you want multiple repositories, one for each project, or a single repository containing multiple projects; there are trade-offs either way. If you change your mind later, you can always change it -- combine multiple repositories into one, or split a monolithic repository into several smaller ones -- but again both operations come with consequences.
