Handling Upgrades
I would like comments on creating a procedure / methodology for handling upgrades to a moded system.
I realize it is the client's responsibility to document and possibly re-apply mods after an upgrade, however, I'm curious how a system such as this would work -
(note I'm not too familiar with diff so your comments are welcome)
- keep track of all the custom changes done to the install, most importantly the filenames.
- So I have a list of files -
login.html
styles.xls
buttons.dlt
email.gif
calendar.gif
- Copy the entire \luminis code tree to anther location, we'll call BEFORE
- Upgrade / Patch the system
- Diff the entire new code tree ( /Luminis ) with the BEFORE
- get a list of filenames that have changed
channels.java
login.html
tabs.jsp
snailmail.gif
- compare these two lists and it would result in
login.html
- The Result : instead of looking at my original 5 files I modded, I only have to look at login.html
I think I remember that diff can even display the lines that are different, so if one of you unix pros can figure out how to create a 'patch set' from the comparisons and apply it to the new install, that would simply rock.
If I'm way off base, let me know that too.
-Jon
diff/patch is the way to go
Jon,
I'm familiar with the Unix diff and patch utilities. It's probably the way you want to go.
Now I don't work with Luminis, but here's how I would guess it could be done:
Have two copies of the Luminis install... one being the "vanilla" install and one being the "modified" install. Use the diff utility to create a recursive, context diff of the two directories.
Next, go through the resulting "diff", making sure that what's in there are things that you actually modified. E.g. if there are generated files or program data files you may not want them to be part of the diff. This diff then becomes your "patch set".
Now do your new Luminis install into a new directory. Verify that the new version of Luminis is working before applying your changes.
Now apply your "patch" to the new Luminis install. This is a reasonably safe operation... if the patch utility sees changes to the same line that it's going to modify it will skip that part of the patch and print out a warning like "patch #5 failed".
For each part of the patch that failed, load of the files in question manually and make the changes yourself.
Warning: I've never done this procedure--I'm making a number of assumptions about how Luminis is setup--so take this info with caution.
Patch Set
Thanks for the post Jason !
I'll have to give that a try on a test machine. I'm really curious if it would work. If it does, I think it'll be embraced by the entire Luminis community and SCT.
What a better thing to offer than - If you've heavily modified your installation, follow these steps to ensure the modifications traverse through the upgrade
Very cool. I'll post later on my progress with this. If anyone else wants to give this a try, let us all know how it goes.
diff/patch
Well, diff is certainly a utility you can't live without....whether it be a nice visual diff (perhaps you want to look at freeware versions of csdiff or examdiff for windows...or any number of open source ones for *nix) or it's command line flavor.
I don't know if I'd personally recommend automating your local modifications this way using patch utility. I think the patch utility works best when the codebase is in a controlled state...and you/we/I don't control the Luminis codebase, SCT does. I have not tried it myself either, so maybe it works just fine. But, in my way of thinking, you're just going to end up doing the whole thing manually using patch anyway because you don't control the codebase.
patch works wonderfully in instances where you have a static piece of code, or a build. For example, the linux kernel. Then, a fix is released that needs to be propogated to multiple people. A patch is released, and each user can apply the fix to their local build, and I as the creator of the patch can be relatively confident that it's going to work the same way for everyone using that particular build.
Another complication I see is the packaging of things in jar files. You might end up having to write a wrapper script around patch to extract things from the jar file and then repackage it.
My interests lie more in the area of version/change control. My collegaue was using Dreamweaver (I think) for a while, which has some integrated cvs capabilities. But I didn't like what it did to the cvs repository, it got very cluttered and there were a lot of needless updates.
We're in the process of evaluating MS Visual SourceSafe, and I've also entertained the idea of slapping cvs over the top of certain Luminis filesystems rather than trying to maintain a separate reponsitory.
Version control systems give you integrated 'diff' functionality. For example, say I put version 1 of luminisFile.jsp in a reponsitory. Then I customize it and 'check in' the new file to the repository. The version control system tracks both versions. I can compare them, revert to the old one, etc. Then, when SCT releases an upgrade to luminisFile.jsp, I check it into the reponsitory again. Now I am presented with the same problem - how do I get my changes into the file. Maybe it's a simple patch/merge...maybe it's going to require more complicated changes, or maybe SCT's new version renders my modiciation not necessary.
Anyway, in my long winded way, I'm trying to expand on some of Jason's above comments and suggest you investigate version control systems. Rather than maintaining one 'vanilla' copy and one modified copy, you can then maintain all versions of the files you place in the version control reponsitory.
hth,
Scott Spyrison
Great thread!
Anything would be an improvement to what I am doing now which is visually checking each directory where I have mods and seeing if there is a new timestamp. If so, then I do a diff or search for my *LSU MOD* tags. If it was changed then I download both files to my computer and use notepad++ to merge code and upload back into place. It takes a while.