On 4/20/07, ossi petz <ossipetz@hallo.ms> wrote:
> hallo
>
> i would create a branch to keep 'my own' things together:
>
> - xamp 1.0 original (put in trunk)
> - create a branch 'my own 1.0'
>
> change everything you need in your branch.
>
> when xamp 2.0 arrives, replace the trunk files (well update them)
>
> then create a new branch 'my own 2.0'
>
> then merge the changes from branch 1.0 to 2.0, if only configs are
> affected (no recompiled executables, images, whatever) things may go
> pretty well. but not completely automatic. thats an illusion ;)
Thanks a lot Ossi, great ideas.
I've already got a working setup that I want to import. I also just
realised I won't be able to actually use this Apache/WebDAV setup as
the server for svn, at least not in managing this "project", as the
server processes need to be shut down while doing a commit. I'll just
use svnserve, and in fact probably set this up as a separate
repository eh?
So how about this approach:
I do a fresh generic install of (my base) xampp v1.60a
"SUBST path-to-xampp-parent X:" so it looks like it's installed in X:\xampp\
Run the setup batch to update all the .conf files
Import the whole shebang (maybe 2GB?) into trunk
Rename the original source directory of the import, shortly to be deleted.
Check out from svn back to X:\xampp and test everything's OK (why
wouldn't it be?)
Do a "snapshot" svn copy to \tags\virgin-1.60a
Then I get the add-on packages I want installed, including Perl and
Subversion (special dav .so's for v2.2 Apache), get everything
configured and working
svn add all files not yet tracked and commit to trunk
Do another snapshot svn copy to \tags\1.60a-w-addons
At this point everything is still 100% vanilla generic, nothing is "my
stuff" yet, but should be 99% the same as what I'm currently running,
not counting the content stuff under htdocs.
So next step would I guess to be to go through my usual manual
"upgrade procedure", ideally for the last time:
Tree-level diff compare between my production directory and the
svn-managed working tree location
Copy over all files that aren't the same (my stuff) into the working tree
Then svn add all the new files and commit.
So here's where you (Ossi) would recommend switching to a new branch
called "my-own-1.60a" and committing to that, not the trunk?
I would have thought it more logical to keep "my own" working
production tree as the trunk, and to keep "virgin version snapshot"
sets as separate tags?
There's a new version 1.61 out that I want to try. Following this
latter scheme, I would think this would work:
Move my working tree out of the way
Checkout \tags\virgin-1.60a into the same X:\xampp location
Unzip the full v1.61 virgin setup there, overwriting the previous version
Run the setup batch and test everything's OK.
Then svn add all the new files and commit to a new \tags\virgin-1.61
(or is this a merge operation? I want to diff compare to \virgin-1.60a
not to trunk)
Install add-on packages, configure and test
svn add the new stuff and commit (merge) to \tags\1.61-w-addons
Delete and then do a check out to test everything's OK (why wouldn't it be?)
Note neither of the new tags contain any of "my stuff"
Now here's where I get confused. I guess I don't want to do anything
between the two working trees, as they each have their own separate
.svn tracking going on? Seems like I should do a merge from the
latest-version-virgin \tags\1.61-w-addons
into trunk, where all "my stuff but v1.60a" resides.
Then I would check it out from trunk to a new folder, if everything
works delete my old working v1.60a tree, left with only the one main
working tree trunk, which is in fact my running server.
From then on, day-to-day development operations (mostly content work,
but maybe some config tweaking) I just do periodic commits into trunk.
Software installs / upgrades / removals get done to a temporary
checkout from the last virgin tag, configured and tested, then
committed (merged?) to a new virgin tag.
Then merge from there to trunk. Once I'm more confident I'll just
update directly from trunk to the working tree rather than doing the
rename/fresh-checkout belt-and-suspenders routine.
So feedback please on my "virgin tags, keep my stuff in trunk" as
opposed to Ossi's "virgin in trunk my stuff in branches" approach?
And of course if this whole concept is nuts let me know!
If not, this seems SO COOL in principle - big question I've got is
why don't all sysadmins manage their servers this way? Rollback your
system back to any point, recover any content files as of a particular
date, etc. Sure, disk space is an issue, but not an expensive one,
what, ten fifteen cents a GB these days?
Some files (tmp, maybe logs) should be set to Ignore, but these should
be easy enough to spot the comparing with the virgin tags, encourage
you to clean up anyway right?
I'm still assuming I should be versioning the binaries, just need to
figure out how to make sure svn knows they're binaries, read about
automatically setting mime-types from file extensions. Or is that
completely unnecessary, as I read that svn itself treats data as data
anyway, what's the advantage?
More feedback please!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 20 13:17:41 2007