Integrating TU/VP/AMS

[vanhuffel]

I am very impressed with the suite since purchasing three seats this past week.

However I am not sure the best way to integrate all the means available to keep it all up-to-date.

I wrote a project in AMS that is a document launcher. Users have it on a USB thumb drive and when run it needs to be able to check/update any of the 200 or so .pdf and .doc files that it launches. This way the users (who *must* always have the most recent versions of the regulations on the thumb drive) will have a truly hands-off way to always have the most current docs.

I use a freeware program called updateXpress to check AMS's "docs" folder and automatically update any file that is newer on the server. It's a slick way to update these individual files, but I would like to use TU and VP to do the same.

Here's my dilemma: I like that VP makes it very simple to do updates, but since I might update a file here and there daily, it would require daily versions and subsequent backups of each day's version--since each version requires that day's build be maintained in a separate directory.

TU seems good for this, however, it's more manually intensive and I need to pass off the maintenance of this program to luddites who need it to be VERY simple.

I am interested in getting some ideas on how to leverage the $3000 we just spent on the suite and make the boss happy, and avoid the project crashing when I get promoted/move/etc. There will be 1500 users of this project and the accuracy of the product needs to be 100%, as it's aviation safety-of-flight related.

Also, can I use VP to do updates of the actual AMS program, and TU to do updates of individual files?

Lots of words, but thanks for your attention/help everyone!

-John Van Huffel

[Desolator]

TU normally is used to check for a new version across various servers and download a patch file.

VP is the full-history patch that patches all changed files.

AMS can do 'em all if you know how to code.

[vanhuffel]

Do you mean that I could write script in AMS to check versions, and update each file?

I can generally figure out how to steal someone else's code, but I'm not so smart as to write much from scratch...

I've been sitting here for a few hours just trying to figure out how to get started with TU, and I'm hitting my head on the proverbial wall. Wish there was some tutorials/examples of how to use it. It seems very code-oriented, and I was hoping it would be more drag-n-drop. Also, it seems, even with the wizards, that you need to check the version of the main application (or have it check each of the 200 files that I want to keep updated) and that seems like a lot of work.

I just want it to look at my build folder on my machine and compare the files on it to the ones on the user's computer and then copy over the new/different ones.

Other than writing a HUGE script that would require constant care/feeding, I don't see how TU will help in this case.

And if I change files every day, how would VP keep a user up-to-date when it may be weeks before they can get to the LAN to update?

There's got to be a way!

Thanks, John

[Lorne]

Originally Posted by Desolator

TU normally is used to check for a new version across various servers and download a patch file.

VP is the full-history patch that patches all changed files.

AMS can do 'em all if you know how to code.

AMS can't do differential patching at all, so it can't take the place of Visual Patch unless you're happy with redistributing patches that are as big as the original files. Although it's technically possible it requires a lot of advanced scripting to implement a reliable update system in AMS.

[Lorne]

Originally Posted by vanhuffel

I've been sitting here for a few hours just trying to figure out how to get started with TU, and I'm hitting my head on the proverbial wall.

TrueUpdate is a very advanced tool, but if your needs are simple it's pretty straightforward. The hard part is knowing/deciding what you want your software update process to be.

It all boils down a few key decisions:

1. How do you know what version a user has installed? (registry entry? version.txt file? etc.)
2. Where will you put the TrueUpdate server files? (e.g. what web url)
3. What needs to happen when a new version is available? (e.g. download and run a patch)

Also, it seems, even with the wizards, that you need to check the version of the main application (or have it check each of the 200 files that I want to keep updated) and that seems like a lot of work.

There's probably no need to check each of the files. You could designate a single text file as a sort of "version marker" and make it always contain the currently installed version. Or an INI file. Or store the current version somewhere in the Registry.

I just want it to look at my build folder on my machine and compare the files on it to the ones on the user's computer and then copy over the new/different ones.

Let Visual Patch take care of that. Use Visual Patch to build patches for the versions you want to update -- it will figure out what's changed, even between multiple versions, and package it all up into a single executable. Use TrueUpdate to deliver the patches. All you need is to give TrueUpdate a way to tell that there's something newer available than what the user currently has.

Other than writing a HUGE script that would require constant care/feeding, I don't see how TU will help in this case.

It helps to keep the software roles in perspective:

Visual Patch builds the patches -- the executables that actually transform the files of one version into another one.

TrueUpdate builds the automated delivery system -- the system that will take care of finding out that a new version exists, and then downloading the correct patch, and then running it.

There is a bit of overlap in capabilities between TrueUpdate and Visual Patch (and if you wanted, you could use TrueUpdate without Visual Patch, and have it download and replace every file on its own, but as you pointed out, that can be immensely complex).

One point of confusion for some is the version detection logic. Visual Patch and TrueUpdate both need to analyze the version situation on the user's system -- but for different reasons.

TrueUpdate just needs to know if the user's out of date. ("Okay you have version 5.22, I actually have 5.23 right here, let me take care of that for you...")

Visual Patch needs to know if the user has a version that it is able to patch. ("Is this a version I know how to patch?")

Note that if you're using full-history patches, TrueUpdate doesn't need to care what specific version the user has, just that it's older than the current one it has available. So your TrueUpdate script shouldn't have to change (other than changing the current version number every time you upload a new patch).

And if I change files every day, how would VP keep a user up-to-date when it may be weeks before they can get to the LAN to update?

If they have internet access, you can set it up so they'll be kept up to date automatically. If they don't have internet access, they'll only be updated whenever they connect to the LAN.

[vanhuffel]

Great minds think alike. I thought I would create a text file that we could post revisions-- using date [2007.5.28 for instance] as a reference or "version number" Then when I update some of the 200 or so .pdfs I'll list the new files in the text file and use TU check modification date of the index file to see if it needs to update.

Would I have to keep completely separate versions of the entire (700MB) project every time I update one file and build a patch for it? Reading about VP it says that it's recommended that you keep a separate copy of the entire thing for each revision.

I would want to only keep the most current version.

Could this work? Will I end up with hundreds of tabs in VP, one for each time I change a file?

Thanks!

John

[Lorne]

Originally Posted by vanhuffel

Great minds think alike. I thought I would create a text file that we could post revisions-- using date [2007.5.28 for instance] as a reference or "version number" Then when I update some of the 200 or so .pdfs I'll list the new files in the text file and use TU check modification date of the index file to see if it needs to update.

Yep, that would work fine.

Would I have to keep completely separate versions of the entire (700MB) project every time I update one file and build a patch for it? Reading about VP it says that it's recommended that you keep a separate copy of the entire thing for each revision.

Yes, in order to build the patches you need to keep the older versions around -- Visual Patch needs the old files so it can perform binary differencing between them and the new files.

However, if you aren't concerned with building full-history patches all the time, you could just get by with two versions: the current one, and the previous one. (See below.)

I would want to only keep the most current version.

Could this work? Will I end up with hundreds of tabs in VP, one for each time I change a file?

Yes, if you want to be able to build patches for all previous versions (a full-history patch).

Alternatively, you could just set up the project with fewer tabs, and (once you have an easily manageable number of tabs) simply delete the tab for the oldest version whenever you add a new one.

The simplest approach is of course to use two tabs: one for the current version, and one for the previous version. Instead of building full-history patches, you would build incremental binary patches. Which isn't a bad idea in any case, since they're smaller.

The only caveat is that if a user is a few versions out of date, they will have to apply more than one patch. For example if a user has version 1.2 and your current release is 1.6, they would have to apply patch 1.2->1.3, then 1.3->1.4, then 1.4->1.5, then 1.5->1.6.

Since you're using TrueUpdate, this isn't that big a deal for the users, since you can automate the process for them -- however you will need to script TrueUpdate so it knows which patch to download and run for each version.

Another approach is to do a "limited history patch," which is basically just a patch for the most recent "x" versions, where x is whatever you think would be manageable.

For example you could have three tabs (the previous version, and the one before that), or four, or however many tabs you like.

It all depends what your particular needs are.

[Desolator]

Originally Posted by Lorne

AMS can't do differential patching at all, so it can't take the place of Visual Patch unless you're happy with redistributing patches that are as big as the original files. Although it's technically possible it requires a lot of advanced scripting to implement a reliable update system in AMS.

You can 7zip the files or even UHA them and they'll get fairly small. But it'd be quite CPU intensive, thus not a good replacement for VP's binary differencing, unless your get DeltaMAX.

[Lorne]

Originally Posted by Desolator

You can 7zip the files or even UHA them and they'll get fairly small. But it'd be quite CPU intensive, thus not a good replacement for VP's binary differencing, unless your get DeltaMAX.

Yep, it all depends on the file sizes. If they're small text files, it might not matter much (especially with a solid-archive implementation of LZMA). But if you're dealing with 512 MB data files, LZMA isn't gonna cut it.

You're right though, DeltaMAX + Autoplay would be a nice combination. It wouldn't be quite as easy on the developer in terms on managing versions and such, but you could definitely create some cool patch interfaces with it.

(*A really nice exercise for anyone evaluating a patching tool is to try it out on a 1 GB file. Back when we were evaluating other tools, we were shocked by how many of them choked on anything larger than 80 MB.)