mtdean at thirdcontact
May 25, 2007, 8:57 AM
Post #2 of 11
(1064 views)
Permalink
|
|
Re: Best way to use SVN version for deployment?
[In reply to]
|
|
On 05/25/2007 11:31 AM, David Frascone wrote:
> I typically build separately on my backend & frontend. I just do a
> snv update, and then compile everything.
>
> But, now I'm adding a separate backend, and it's time to upgrade svn
> (why not?), so I thought I'd pose a question: How would you recommend
> doing the svn build? I can think of a couple of possibilities:
>
> 1) Have separate build directories on each machine. Update one, make
> not of the rev. Then update all others with -r rev, make everywhere
> and deploy.
Better approach. Saves bandwidth. Create some directory which will
contain your source (I used MythTV/src :). Change to that directory.
Checkout a clean copy of source:
svn co http://svn.mythtv.org/svn/trunk/mythtv &&
svn co http://svn.mythtv.org/svn/trunk/mythplugins &&
svn co http://svn.mythtv.org/svn/trunk/myththemes
Then, use the following to update all to the same rev and tar it up:
( echo Last Updated: `date` | tee mythtv-update.log &&
exit $PIPESTATUS ) &&
( svn update mythtv mythplugins myththemes 2>&1 |
tee -a mythtv-update.log &&
exit $PIPESTATUS ) &&
tar cjf ../myth-`date +'%Y%m%d_%H%M%S'`.tar.bz2 *
That puts a file (i.e. myth-20070525_003429.tar.bz2) in the parent of
your source directory. The mythtv-update.log shows you the date/time
you updated (head -n 1), the changes since your last update, and the SVN
rev (tail -n 1)--all nicely bundled in a tarball. If you prefer to show
all the updates, change "tee mythtv-update.log" to "tee -a
mythtv-update.log").
Then, untar that tarball on your other machines. Only one svn up
required and guaranteed that all your systems have the same rev. It
also makes it easy for you to "clean up" your build directory (i.e. I
often add a bunch of files to my working copy while hacking and never
have to track down the extras when I'm done).
When it comes time to update again, "rm -rf *" in your src directory,
then untar the old tarball and re-run the update commands above. On
other machines, "rm -rf *" in your src directory and untar the new
tarball. This ensures you always have a pristine copy of the Myth trunk.
With this approach, you'll never have a merge conflict due to changed
files in your working copy. You'll never be caught off guard by a
"requires a make clean" or "requires a make distclean" commit (as you're
always starting clean). However, because of this, the biggest
recommendation I have for this approach is to use ccache. Otherwise,
you'll spend a lot of time recompiling everything every time.
I just maintain a patchset that I apply to the pristine copy I untar
each time before I build. See, also, quilt.
I'll probably chuck Myth into my subversion server one of these days as
a vendor branch, but I haven't gotten around to that, yet.
> 2) Use one shared build directory. Update once, and install
> everywhere. Not sure how well this would work, since my backends and
> frontends are a mix of P4's and xeons.
>
> What would be safest?
Safest is, by definition, to compile on each machine. I compile once on
my AMD Athlon XP 2400+ backend, then tar up the (compiled) src directory
structure and untar it on my Athlon XP 2000+ backend.
I--obviously--build a separate build on my Athlon X2 4800+ running in
64-bit mode. This works for me because my backends are basically
identical. When you have differences things get exponentially more
complicated.
This may not be the "best way" to use SVN, but it definitely works
well--especially for untrusting OC types like me that don't trust "svn
revert -R ." or even "svn up" depending on changes that have been made
to your wc.
Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
