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
Here's what I have right now (not under version control, except
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
What I want to have is a directory structure like this for the working
/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
/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
- 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
(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
(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
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!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Dec 1 05:59:07 2004