Vega Strike Forums

So i'm getting ready to start the svn repo from scratch. Not sure exactly how I want it setup so here goes.

Start with the usual branches, tags, trunk. The tricky part though is what now goes where.

I figure we can use trunk for the mainline data/engine code that gets shared between PU, WCU, and any other WC mod that pops up. Branches though will have more mod specific content as well as the separate lines ie branches/paralleluniverse, branches/wcuniverse etc.

Sound good or should we set it up in a different way? Once we get this operationl I can get the svn setup to make work a lot easier than it is now (and make the svn a LOT less cluttered).

I already downloaded the entire cvs repo before removing from the project. Will do the same for wcu before start a fresh svn

For PPU I will start from the cubemaps branch line that chuck had up. I will check all files from both ppu lines though to make sure that in either case the most recent will be used. I willl also be opening up the ppu forum here again since chucks forums are toast (there was sooo much usual material there.. shame its mostly gone )

Anyway, let me know what your thoughts are on this so I can get this up and running quickly.

No one has any input?? I will give it till this weekend then I shall revamp the svn

It's just no one really knows what to say You might consider having the bin be external pointing to the vegastrike repo.

Enjoy the Choice

I just read this. But yeah... not much to say. Besides, moving things around in SVN is rather easy, so no need to marry any specific setup.

loki1950 wrote:It's just no one really knows what to say You might consider having the bin be external pointing to the vegastrike repo.

Well the current WCU project svn is a big mess, plus it is extremely dated.. not telling how much of what chuck did or travis has done would break once added to current svn.

As far as pointing to win32 bin... It's possible though I think for WC based mods having a WC or Priva based app icon would look better. Not a big deal though.

Removed the old svn (after backing it up) and getting a fresh one installed. I have run across something though.. Should we give Parallel Universe its own project or keep it rolled up with WCU?

Keeping them separate will ensure no cross contamination between data sets but brings its own hassles.

Keeping them together though.. I actually have an experiment to run on this. I can have one installer that will download the dataset for either rather than having two separate installers.

Just some ideas I have bouncing around in my head.. still have to finish cleaning out my PU directories (have no idea what changes were made in spiritplumbers branch of PU w/o logs)

Well... they're related.

The only thing with keeping them together, is that it makes file downloads a bit more confusing (you know... you can only have one default download).

But I'm not sure that matters much for WCU

Well the single file download isn't an issue (at least for windows). While looking for the stupid boost 1.51 boost binary package (that isn't on the boost project file page) I ran across a site called boostpro that had a very interesting installer for windows. I don't know if it was an add-in for the nullsoft installer or a fork of it (haven't checked) but it allowed for differing downloads and even differing download location ie sf.net, a choice of several sf.net mirrors, the boostpro site, and some other site I cannot recall.

I am pretty sure it can be configured for our use in any of the current VS based projects. We could package one single binary for all projects to use and just have choices for each dataset.

something like... Now if only we had that for linux (or is it possible/already there?).

Since none of them, to my knowledge, use a custom VS binary it would cut down on problems with tracking engine bugs.

pheonixstorm wrote:Now if only we had that for linux (or is it possible/already there?).

Since none of them, to my knowledge, use a custom VS binary it would cut down on problems with tracking engine bugs.

RPM?

Whatever works How would that affect packaging for all the other distros? No issue or are there a few that barf on rpms? I've only used gentoo, SuSe 8.1/9.1, ubuntu, early Red Hat, and Mandrake. Never did get my debian, slackware, or calderra installed.. may still have those old disks though.

Well, RPM-based distros all have the option of installing LSB RPMs (that is, one RPM that works for all).

There's also source RPMs, or pull-in RPMs. What you do looks like a pull-in, where it's a small RPM that downloads all sources, the RPM depends on the stuff needed to build, so installing the RPM means installing all the stuff needed to build, download the sources, data, and then BUILD.

nVidia's driver and adobe's flash, for instance, are pull-in RPMs.

For debian, you could do the same with .deb.

Writing the RPM specfile, though, is a chore. Opposite to an RPM that is supposed to be built on a build farm, such an RPM must work on every user's configuration. It may be tough to get right. Remember, windows has standard binaries, linux doesn't (it has LSB, which is mostly the same, but I never tried building an LSB rpm).

Yeah.. I was reading that even though standards are out there for various things linux they are often ignored. Shame too... If the linux community would get its act together and create one set of tools for some things and stick with it then it would make the lives of noobs to enterprise admins a lot easier. Oh well, at least Steam works on Ubuntu