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 _______________________________________________ Live-demo mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/live-demo
