[Live-demo] 2.0.3 testing

[Hamish]

Cameron  wrote:
> Hamish, I think this is a good idea,
> in particular being able to create a freeze of a build
> scripts so that it can be reproduced later.
> 
> I suggest going one step further.
> Our build process starts by downloading everything from
> livedvd/gisvm/trunk/ 

the only change you would have to make is to replace trunk/ with
$VERSION/.

> and get we use wget to get files out of svn during the build process.

right.

> What I suggest is that we:
> 1. Instead of sourcing files by "wget -c http://svn.osgeo.org/livedvd/gisvm/trunk/dir/file" we
> should source the file from the version we have already
> downloaded which is currently at:
> "~/gisvm/trunk/bin/../dir/file".  We can rename the
> gisvm svn directory so that it is one below trunk, which
> will make scripts easier to run.

I'm not sure if you mean rename the top dir in svn (I'm not a huge fan of
that) or to save the copy locally at /usr/local/share/gisvm/[bin|doc|...]
instead of /usr/local/share/gisvm/trunk/[bin|doc|...] (I'm a big fan of
that idea)

none the less, for this release/tag it is now history and my main
intention is to archive that, warts and all.

after tagging 2.0.3, sure go for it in the release branch. but we
shouldn't start rewriting history any more than necessary in the mean
time.
 
> I suggest that we start making use of the tags directory.
> So that I can check out the 2.0.3. At times it is important
> to distinguish between 2.0.3 and 2.0.4 if there are users
> for both version.

yup, that's exactly the idea.

> This is more important than using the branch directory. In fact, I
> suspect that we will avoid the need to use the branch directory for
> the most part, unless we decide to create an "unstable" build list
> and a "stable" build list.

The release branch is needed & useeful, really 2.0.4 should come from
that not trunk. Otherwise you tend lock up & hold back trunk for any new
development which necessarily requires divergence and breaking with the
old ways. It doesn't really cost nuthin to have it but leaves some doors
open if we need them.

Anyway, the trunk/release branch/tag model is used as standard practice
everywhere Subversion is used, and is similar in theory as to how CVS
worked things before it. I can't really comment on what Bzr, Git, and
Mercurial do to manage these things.

Merging fixes between branches is trivial; I've already added some hints
on the wiki, and there is lots more on the subject in the SVN book:
 http://svnbook.red-bean.com/

So sure it is possible to break from traditions, but in general it's well
worn ground arrived at after years of toil, so I would argue to adopt the
norms and take advantage of the fundamental benefits of using svn. 

(just my 2c)


> 2. I suggest that we store a copy of the /tmp download
> directory. Some projects are likely to move their download
> source location, and if they do, then it will be hard for us
> to reproduce an old release.

This is a very good idea. SVN is not the place for big binary dataset
downloads, download.osgeo.org or the like is much better for that.
I wouldn't bother archiving the Windows and Mac installers, as they
have such a short shelf life.


I'll wait for word from Alex re. README.adjustments to explain what
happened outside the scripts (if anything) before continuing.


regards,
Hamish