[Hendricks266]

Since I migrated my add-on HRPs to an SVN-only distribution model, I've been considering what it would be like for other things to do the same. Yesterday, I wrote this:

http://hendricks266....svn_checkout.7z

It contains a self-contained SVN client, a batch script which can take inputs, and five other scripts which tell it to check out the five public repositories on svn.eduke32.com. All the user has to do is run the script of their choice, and the repository will download automatically.

Here are the parameters for "_svn_checkout.bat":

Quote

Mandatory:
%1 - Subversion Respository URL
Optional:
%2 - SVN Local Directory Name
%3 - EXE Search Target [no extension] [to not search, input "\"]
%4 - Project Name [full/proper]
%5 - Project Name Short Form/Nickname

I think that, with the exception of something like a GUI installer for major versions, this should become the method used for distributing the HRPs. The only issue is cross-platform compatibility. Preliminary research says that most Linux distros and recent versions of Mac OS X include SVN by default, so all that would be needed are bash scripts and AppleScripts.

Of course, this would only stand for projects that have their own repositories (polymer_hrp, dc_hrp, vaca_plus, nw_plus, sw_hrp). Other things without need of frequent updating and without repositories would keep their zips.

Pros:
less bandwidth used
easier updates for the user
supports stopping/resuming for dial-up users

Cons:
slightly more work on the user to download initially

EDIT: Poll added.

[Hank]

Well, as an outsider, I like it. I am on windows, and even without a .bat file would be willing to hook up on an SVN.

[NightFright]

I am still dreaming of some sort of auto-updater for the HRP which checks if a new file has been uploaded to the Duke4.net servers and offers to update the current file with the new one. The concept would probably still require someone to pack together the files to a zip, but it'd be a step forward. You won't get chances to test new contents on the fly this way, but it has some advantage since I usually check stuff before I upload it. Therefore, there would be some guarantee that what is offered to you really works. Also, it should be admitted that new stuff is not really added that frequently any more.

This imaginary auto-updater could:
> Check if your full HRP file is outdated and in that case offer to download the new one (same with maphacks as long as they stay in a separate file)
> Check if there are update packs if your HRP is up to date and download those instead (and keep those updated as well)
> Check if there are new EDuke32 snapshot builds and offer to download/install them (optional, but would be cool)

Before downloading, it would also tell you how big the file is, so you'd be prepared for what's coming.

If anyone out there were able to pull this off... bazinga! ^^

[BrentNewland]

I would be quite happy if the official HRP downloads included an "svn_ver.txt" file which contains the SVN revision (just the number of the revision, nothing else). That's enough for my software to update it.

[Jblade]

I'm almost 100% certain that the vast majority of people don't want to fuck around with SVNs and are happy with downloading the zip files every now and then when they feel like checking out Duke with the HRP. It's nice for people who want to be at the cutting edge or are working on the HRP themselves, but for casual players it's really just easier to give them a zip file.

[TerminX]

Alternatively, we could just install a commit hook on the HRP svn repo to automatically throw a zip of the current revision up somewhere whenever it's updated. That way people would easily be able to download the latest revision without having to fuck around with a svn client or some batch file.

[Hank]

James, on 05 July 2011 - 01:36 PM, said:

I'm almost 100% certain that the vast majority of people don't want to fuck around with SVNs and are happy with downloading the zip files every now and then when they feel like checking out Duke with the HRP. It's nice for people who want to be at the cutting edge or are working on the HRP themselves, but for casual players it's really just easier to give them a zip file.

I beg to differ. Most people nowadays, download a program that comes with an automatic update system. Whenever there is a need for an update the user gets an offer to update said program. Meanwhile, those on the SVN, are people that are mostly beta testers (or like me fans) and monitor the development. So when something new happens, they get first crack, to assure the development is on track. The benefit here is closer relation to the main stream public and smaller downloads. Instead of re-downloading the entire thing you only download what is updated.

Hendricks266, offers agood start methinks, and of the looks of it BrentNewland is working on the outfront part, like a MSI style program. I wish them both my very best, and hope the rest team may at least consider supporting them.

[Plagman]

End-users wouldn't want to be kept up to date to every SVN revision, but rather only be notified when a new release is cut. Getting all revisions would mean ending up with WIP material that's not meant to be seen.

[Hendricks266]

Plagman, on 05 July 2011 - 06:27 PM, said:

Getting all revisions would mean ending up with WIP material that's not meant to be seen.

Could you give an example of something that is really WIP and uploaded to the SVN even though it's not meant to be seen? Most commits are perfectly good, final content submissions, and I bet that the artists themselves would like to have their work distributed to and seen by the masses as soon as it's ready. I certainly like for users of my HRPs to experience benefits as I make them, and I even added functionality so that the SVNs are automatically updated. Of course, now and then we have a bleeding-edge bug since I'm working with batch files, but by the same token I can fix them just as quickly. The HRP, as it stands now, would not really have to worry about something like that.

[NightFright]

It should also be taken into consideration that it happens often to see minor stuff being added for which you really have to look closely ingame to notice it. Most people won't notice any difference at all when updating SVNs from one version to another. I am sure most people - besides folks contributing to HRP contents and maybe some others - are fine with a longer waiting time if they get something with noticable differences compared to the last release. I could be wrong ofc, but it's probably all a matter of effort, anyway. I wouldn't mind any solution actually.

[Micky C]

I'm one of those people who always like to have the latest stuff, and I assume there are many others out there that are like me in this respect, but they're all welcome to set up their own repositories as is explained in the sticky thread, and it's very easy to do.

[Hendricks266]

Micky C, on 06 July 2011 - 01:28 AM, said:

I'm one of those people who always like to have the latest stuff, and I assume there are many others out there that are like me in this respect,

Poll added to determine this.

Micky C, on 06 July 2011 - 01:28 AM, said:

but they're all welcome to set up their own repositories as is explained in the sticky thread, and it's very easy to do. [emphasis mine]

A lot of people would disagree about the ease of having to install TortoiseSVN, then fill in a dialog box with exact parameters. That's what I hope to alleviate with my script.

[Master Fibbles]

I don't really have a preference either way except that I don't like large downloads. I have the current HRP and updates etc so it isn't a big deal right now but if something major happens where I have to download a completely new pack, I'll sit hoping the download doesn't stop part way through for some reason.

Anyway, I'm open to an autoupdate thingy.

[Skulldog]

The script works for me, but a updated zip should always be available.

[BrentNewland]

There are a few problems with using SVN for updating a program:

-Leaves a bunch of SVN folders everywhere
-If a local file is corrupt (or didn't download properly) it's not easy to verify and redownload
--Or if you changed or deleted something
-No way to export the differences between two revisions (besides doing it one by one)


The perfect solution for me would be to have a script on the server that generates one main index file that has a list of every file in the HRP as well as a hash of that file. With that, I can quickly check that every file in the HRP is valid and download updated versions.

[Hendricks266]

BrentNewland, on 13 July 2011 - 02:18 PM, said:

-Leaves a bunch of SVN folders everywhere

I agree. Git does it better with just one .git folder in the root. However, this is a very minor problem, and it almost doesn't matter at all.

BrentNewland, on 13 July 2011 - 02:18 PM, said:

-If a local file is corrupt (or didn't download properly) it's not easy to verify and redownload
--Or if you changed or deleted something
-No way to export the differences between two revisions (besides doing it one by one)

The perfect solution for me would be to have a script on the server that generates one main index file that has a list of every file in the HRP as well as a hash of that file. With that, I can quickly check that every file in the HRP is valid and download updated versions.

SVN can do all these things.

Verify and redownload:

svn cleanup
svn update

Show locally changed files:

svn status

As for exporting the differences between two revisions, it depends on whether you mean just a list of what files changed, or an actual patch from one version to another. For the former:

svn log -v -q -r <first version>:<second version>

I don't see why either would be important for you to use. In fact, SVN takes care of all of this for you: updating, and displaying to the user what it's doing.

Your "perfect solution" is unnecessary and redundant, even facepalm-worthy. Try running "svn help" and take a long look at all the commands that are available.

[BrentNewland]

If you wish to leave a ton of .svn files on the system (or have to zip them up), then SVN works fine. I don't want to leave those files lying around - they double the space taken up on the disc (and as a result double the time it takes to compress and decompress the zip files, and I wouldn't be surprised if it increased loading times for EDuke32). I export from the SVN server to a local folder and package it up. When working like that, everything I said in my post applies.

Quote

SVN can do all these things.

Verify and redownload:

svn cleanup
svn update

Show locally changed files:

svn status

As for exporting the differences between two revisions, it depends on whether you mean just a list of what files changed, or an actual patch from one version to another. For the former:

svn log -v -q -r <first version>:<second version>

I don't see why either would be important for you to use. In fact, SVN takes care of all of this for you: updating, and displaying to the user what it's doing.

Verify/redownload: Does not work without .svn
Show locally changed files: Does not work without .svn
Exporting the differences between two revisions: Please see the command "svn help export". It doesn't work to just download the files changed between two revisions.



I stand by my post. Some way for me to get the hash/checksum for current files in the SVN would be an immense help.

[Hendricks266]

Have you tried re-checking out the SVN using that directory on the destination? In my experience, it may end up redownloading the whole thing, but it's worth a shot, especially if you can find an option to have it not overwrite stuff.

[Hendricks266]

I updated the svn_checkout script as well as my three scripts for the add-ons so that they display the commit log for any changes downloaded when updating an existing local copy.

[Hendricks266]

After a candid discussion on IRC I felt the need to revisit this thread.

I think this poll should be featured on the front page of duke4.net and hrp.duke4.net so we can get a more accurate sample of what users really want.

TX, on 05 July 2011 - 01:46 PM, said:

Alternatively, we could just install a commit hook on the HRP svn repo to automatically throw a zip of the current revision up somewhere whenever it's updated. That way people would easily be able to download the latest revision without having to fuck around with a svn client or some batch file.

The bottom line is, something like this needs to happen. Personally, I would like it if there were two packages: one that is simply an export, and another which actually zips the checked out repository so that the end user can update it on their own.

EDIT: If someone really wants the svn incremental update functionality, they can just use my script which can be hosted alongside the zip.

[ReaperMan]

A zip file should always be available.

[supergoofy]

The majority of the people that play Duke Nukem 3D with the HRP addon need just a zip or installer pack that it will have everything that is needed (except copyrighted material, like duke3d.grp) to play the game with easiness.

Downloading from SVN etc. etc., it's a complex procedure for inexperienced users.


A good poll would be about the new unofficial Polymost HRP by LeoD
http://forums.duke4....loves-and-more/

I think that the Polymost HRP by LeoD should be hosted in the official HRP site.

The reasons are simple:
1. Polymer renderer is not ready yet and even if you have a capable computer, there are still various problems.
2. Polymer HRP is not backwards compatible with Polymost renderer, at least not yet.
3. Not all users have powerful gpus to handle Polymer.

In my opinion Polymer needs at least a GeForce 9600GT 512MB card, but the recommended would be an 8800GTS 512MB card.

[Hendricks266]

If you saw the discussion in LeoD's thread, once the def "ifdef" parameter is implemented it makes the most sense to recombine the two packs. I would be willing to do the def writing required.

[supergoofy]

That would be great Hendricks266. I know that I cannot do that, I don't have the knowledge.

Probably this needs a lot of work, unless it can be done automatically with a vb script or some other way.

[LeoD]

BrentNewland, on 13 July 2011 - 02:18 PM, said:

There are a few problems with using SVN for updating a program:
-Leaves a bunch of SVN folders everywhere

Pojint no longer valid since Subversion 1.7. Only one .svn folder at toplevel (with roughly the same amount of data, of course).
However, I'm in favor of ZIPs because obvious version numbers make life easier when 'bug reports' or simply dumb questions show up. The must-be-up-to-date guys like us will know how to use SVN anyway. (Plus I wouldn't have to maintain my Z-packs on a daily basis. )


I will respond to the Polymost HRP topic in "my" thread, soon.

[Hendricks266]

LeoD, on 27 January 2012 - 10:30 AM, said:

Pojint no longer valid since Subversion 1.7. Only one .svn folder at toplevel (with roughly the same amount of data, of course).

Cool! I did not know this.

LeoD, on 27 January 2012 - 10:30 AM, said:

However, I'm in favor of ZIPs because obvious version numbers make life easier when 'bug reports' or simply dumb questions show up. The must-be-up-to-date guys like us will know how to use SVN anyway.

This made me realize that there is no reason to package zips of a repository with .svn because if users really want that they would use my script which can be hosted alongside the zip. Exports it is!

[Hendricks266]

I updated svn_checkout.7z to include the new SVN 1.7.2. (from http://www.sliksvn.com/en/download)

[LeoD]

Hendricks266, on 28 January 2012 - 02:18 PM, said:

I updated svn_checkout.7z to include the new SVN 1.7.2. (from http://www.sliksvn.com/en/download)

Please note that the .svn data of an existing checkout (Subversion 1.6) must be converted (by Subversion 1.7) before it can be updated with Subversion 1.7. TortoiseSVN 1.7 provides this function in the context menu. The commandline should be something like svn upgrade preceeding the first svn update IIRC.

[Hendricks266]

Yes, although this is intended more for people who download the repos for the first time. Subversion gives an error with exactly these instructions, in any case. It is not worth running "svn upgrade" before every svn update because that will show the user errors that are unnecessary and confusing.

[Tea Monster]

I've worked in tech support since 1998 - I can tell you with authority that 90% of the people out there will ignore it if it isn't download-unzip-run. Worse, you could find yourself caught up in a noobnado of heartbreaking proportions as they all bug you for a zip file.

Keep the SVN for those who know how to do it. Put a zip file up for everyone else.