Repository Creation Plan

OK, having learned some more of how svn works I'm ready to try
rebuilding my repository from scratch again (fortunately I have all my
old files archived so I can start fresh). I'm curious if there are
holes in my plan. I'm a solo developer and at least for now, I'm doing
this under Windows in stand-alone mode (i.e. file system URLs, no
server).

Here's what I have right now (not under version control, except
experimentally):

    A "live" (i.e. current release) branch which is my code base

    A few bug fixes to this code base

    A "development" branch off the same code base with a number of
    changes already made, but without the bug fixes mentioned
    above.

What I want to have is a directory structure like this for the working
copies:

    /top/project/live -- Live code. There are no files in this subdir,
    they are all below it, e.g. /top/project/live/html has the HTML and
    PHP code, etc. There are numerous unversioned files and
    directories below this, and some vendor files, not just my
    versioned code.

    /top/project/dev -- Development code (same structure).

I realize this is not trunk / branches / tags but it fits my needs. I
really only need the two branches, I don't want either one under a
"branches" directory, and I can always create another branch under
project/ if I need to.

Make sense so far?

Is there any reason not to use the same directroy structure within the
repository as I have for the working copies?

To create this I plan to:

(1) Add the base code to the repository:
    - Establish the base live/ directory from my archives
    - Add some files which belong there but are currently
         elsewhere in the directory structure
    - Move unversioned files to a holding area
    - Import live/ directory to an empty repository
    - Add the initial timestamp properties to preserve
         file times
    - Move the unversioned files back to live/

(2) Create the development branch:
    - Use svn copy (URL to URL) to create a dev branch
    - Checkout this branch to dev\, and set timestamps based on
         file properties

(3) Update live directory:
    - Update live/ with those few recently changed files
        not in the base code
    - Commit those changes
    - Deploy them
    - Continue bug fixes, commit and deploy to live server as
         needed

(4) Update dev directory
    - Update dev/ with files and directories changed and added
         since the base code was created
    - Add unversioned files and directories to dev/
    - Continue development, commit and deploy to test server as
         needed

This leaves me with two working copies, one in live/ and one in dev/,
each appropriately updated. Am I missing something or totally lost in
some area? The ideas of what I'm trying to accomplish aren't new, but
using this model to do them is, so I may well have missed something.

Note I have a wrapper script now for checkout, update, and commit which
preserves timestamps using properties. I will have to make that script
also handle svn add and svn merge to be complete.

I also need to synchronize the changes at times. It seems to me that I
will have to do merges in both directions:

    - Periodically merge current fixes on live/ branch to dev/,
         and resolve any conflicts, so development code keeps
         up with bug fixes to the live code
    - When dev/ code is ready for release, merge dev branch back
         to live so it becomes the new live copy in the repository

Does that sound right?

Thanks for any feedback ... I appreciate all the help here!

--
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org