Periodically we receive announcements of new maintenance builds of Oxygen XML Editor. It's easy to locate documentation on installing new versions, but I was unable to find any instructions on installing maintenance builds.
In the past I've renamed the downloaded folder, e.g, "17-1", which completely duplicates all the files in Applications (I'm using OS X), then later on deleted the older folders when it seemed safe to do so.
I would like to know the best-practice, most efficient way to routinely install these frequently released maintenance builds.
Since there is no Oxygen installer for OS X (it's just an archive), there is no straightforward way of upgrading (installing in the same folder), like there is for Windows or Linux.
The official upgrade procedure for maintenance builds (it's the same for minor version updates) goes like this:
To upgrade:
For Windows and Linux you can install the new build in the same folder as the previous installation, it will automatically upgrade it.
Before you upgrade, if you have added files or made changes to any of the files from the Oxygen installation folder (especially the frameworks folder), you may want to create a backup of them because they will be overwritten during the upgrade procedure. Custom frameworks will be preserved but we recommend backing them up anyway, just to be safe.
For Mac OS X you will have to either move the old folder from Applications to a different location and put the new version of Oxygen in its place, or install in a different folder. You can then copy any files you may have changed from the old folder (if any) to the new folder.
The Oxygen preferences will be preserved since they are located elsewhere (user home folder).
What I'd like to add is that, if you have custom frameworks and want to keep Oxygen up to date, it's a good idea to keep the custom frameworks in a different folder (from your user home) than the Oxygen installation folder and simply configure Oxygen to load them from that folder (Options > Preferences, Document Type Association > Locations, Additional frameworks directories). This greatly simplifies the upgrade procedure.
Regards,
Adrian
According to a colleague, his way of doing it, FWIW:
I keep all oXygen stuff in the directory /Applications/oxygen
When I get a new oxygen.zip download, I put it there, unzip it, and rename the directory to the oXygen version name. So right now I have
/Applications/oxygen/17.0
I usually compress the previous version and delete the directory for it, but keep the zipfile for a while in case I need to revert to the
old version
I keep the related jarfiles in /Applications/oxygen/lib so that they don't live in the same directory as an oxygen version that might get
upgraded
I create an alias under /Applications named "oxygen" that points to whatever current version of oXygen Editor I'm using (and it needs to
be updated whenever the current directory changes)
I can't accept this as the best answer unless I receive confirmation that this is the ideal method on Mac OS X. If there is another proposed procedure that is conventionally accepted as the best practice, or a definitive answer from an authoritative source, then I will accept that answer.
Related
I'm learning the Qt Installer Framework and creating repositories on a web server to be used by the online installers. My problem is that even though each repository and installer is treated separately in the creation process, when I run any of the installers they list ALL the programs/repos on our server and check each of them for install. It is of course possible to manually uncheck them, but really I want an installer specific to each program as different departments at my work use different programs and shouldn't have to go through the full list.
I don't understand why the installers are listing everything: each program/package has an individual repository on the server and an individual installer created using a config.xml, installscript.qs, and package.xml specific to that program. Nowhere in any of those files is there a reference to any other program or repository, and I've used the repogen and binarycreator for each individual program rather than as a batch. The only thing I can think of that might be affecting it is that the individual packages are subfolders under the same "package" folder in one unified installer framework folder. I just point the repogen.exe and binarycreator.exe at the desired subfolder. Could this be causing my problem? Do I really need to have a separate installer folder with config and package subfolders for each program?
There's obviously a lot of moving parts to this so I'm not sure what specific code/info I should post, but please feel free to ask me for something that may be helpful and I will provide.
I'm not sure of the details of why, but the answer appears to be that every program needs its own installer folder. It seems that everything under a single "packages" directory is consider a component of the same program, regardless of subfolders or arguments passed to the binarycreator. So if you have multiple programs they each need their own installer folder with config and packages directories. That is unless you want a full list of available programs associated with each installer; and then what's the point of separate installers?
I recently started working with SVN, I am using it in combination with Wordpress.
I just made a number of updates to Wordpress and to some plugins, and I would like to know in what order I need to update, or whether it even matters.
Here is what I did:
Locally on my computer:
svn delete folder xyz
commit the deletion
add a new folder by the same name
svn add the folder
svn commit
Now if I log in to our development server, do I just to "svn update" ?
Or do I need to go through the various versions by updating to specific version numbers?
The reason I ask, is because I have had one or two tree conflicts in the past where I got:
Tree conflict (local dir unversioned, incoming dir add upon update) for location wp-content/plugins/ExamplePlugin/ExampleSubDir
Does my workflow lead to such errors? Am I overlooking something?
Your workflow is fine, and yes, you would just perform a single svn update on the other computer to get fully up-to-date.
The workflow you describe would produce a tree conflict if you happened to have an unversioned folder named "xyz" in the same location as the one you just committed (which is what the error says in the parenthetical remark). You should remove that unversioned folder and then let SVN add that folder itself (via the call to update).
If you haven't already, it might be worth reviewing some of the documentation to ensure you understand the fundamentals.
I'm currently stuck with an Installshield project for installing our ASP.Net Application and need to implement upgrading. From my initial investigation it seems extremely complicated for what is essentially copying over a number of files.
Of the options available: patches and small, minor and major upgrades, what seems to most suit our needs is a patch but it is done as a separate .exe.
Is there a way to include patches in the full setup.exe or another recommendation that makes the whole process less complicated.
EDIT
Any alternative recommendation still needs to be done as part of an installer.
No, there is no way to include patches in the installer setup.exe. Patches, as well as small and minor updates, are applied to already installed application. I mean users already used the original installation package to install your application. And patch update contains only small set of files that are modified.
What you want is a major update. This kind of package contains all the required files, and it can be used to install the application for the first time. In case where the application is already installed, this kind of installation package will automatically remove the old version and install the new one.
If it involves only copying files then IMO, the best option is to give the bunch of files in needed directory structure and ask to overwrite existing copies. A slightly more user-friendly measure would be to zip up the directory structure along with a batch file and ask to unzip it in the app directory under some designated folder and then run the batch file to overwrite files.
recently, i upgraded to Flex Hero 4.5 and created a new workspace. Then, i imported a project from the former workspace and started working. when i tried to upload the project from the new workspace to codereview, i got the error message: could not guess version control system. Are you in a working copy directory? How does one resolve this issue?
thanks
I have read somewhere that i need to checkout my svn but i thought that you only checkout when you want to get a folder/file from the svn.
Sounds like you've got a bit of a mess unfortunately. Hopefully you're not in the habit of doing a ton of changes without checking in. I would suggest you:
Back up your latest changes to a safe location
Check out the project from SVN into your new workspace (which is what you should have done initially) - creating a brand new project folder
Merge the changes you've made into the now-correctly-versioned copy of your project (you could do this by just copying files from the "latest"/project backup folder overwriting the SVN versioned files, but if you do--do NOT overwrite any .svn folders). You could also use a tool such as WinMerge or WinDiff to find differences between the two projects (of course ignoring .svn folders).
If you have a small number of changes it shouldn't be bad, but if there's a lot, you might want to follow SolarBear's branch suggestion, if WinMerge isn't going to cut it.
If I understand correctly your latest comment, you did a svn export on your code. The export command, as the doc mentions, creates a "clean" directory tree, i.e. without the .svn directory. So basically, these are files not controlled by SVN; also, you lose all the history of your files. The best way would have been, I think, to do a checkout in your new workspace and then work from there. It could take some time, but it's much easier to manage afterwards.
One possible way to make this work would be to checkout a clean copy your code somewhere safe and then merge your changes into this clean copy. However, if your trunk or branch changed a lot in the meantime, this could be very, very tedious. I could then suggest to branch your trunk, checkout that new branch, slowly merge your changes into that branch and when you're done and everything's working OK, merge the branch back into the trunk.
I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.
Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.
So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the staging server.
The staging server is running Linux, and I develop on a Windows PC, if that helps.
Thanks in advance.
Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.
The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.
If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).
what we usually do is have a hierarchy of independent subversion repos as follows:
core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries
then we use the svn:externals properties so that if you check out "core" you get every associated repo.
we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).
we use svn commit hooks to update the beta/staging/sandbox site upon commit.
with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.
two last things to consider:
we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.
I hope this helps you.
I second using backup_migrate. It's great.
When I'm installing a fresh site from development to production, I:
backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI
But take a look here for the official version:
http://drupal.org/node/776864
Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...
Andy-