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?
Related
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.
I want to create a master repository on our server, from which I can clone a local version onto my computer.
I am using R Studio v0.98.994.
So far, this is what I have tried doing:
Create a folder for the master repository to live in. I do this using 'new project' in R studio, and tell it to make a git repository.
I can then open up another new project, located on my C drive, and use R studio to clone, by telling it to open an existing project and setting the URL as the location of the master project.
However, then when I make changes and commit to my local repository (which works fine) I cannot push to the master repository, I get an error exactly as described in this question: git push fails: `refusing to update checked out branch: refs/heads/master`
So it appears that R Studio creates non-bare repositories?
Now I thought, well okay, I will use git bash to initialise the repository and then connect to that within R studio.
I do so, but cannot then find a way to use that repository in R Studio.
I am very new to Git, so it is entirely probable that this is one of those 'read the instructions' questions, in which case I am very sorry - and could someone possibly point me towards some guidance for this situation? I have spent the better half of a day googling around this error and haven't yet managed to pull together the pieces :( I also apologise; this doesn't feel like a very reproducible question.
It sounds like you are using Windows Git, with a setup on a local Windows machine (C: drive) and a server of some kind, mounted as the S: drive. There's a few things you should be aware of when doing this.
Shared Repositories
If you are intending for multiple people to share the same repository, you want to initiate a shared repository. See the --shared option in git-init for more details. Note that I'm not sure how having your repository on a Windows machine affects the sharing options. If you are just trying to keep your repository in two places, that makes things a lot easier.
Bare Repositories
Separate from the discussion of sharing is the discussion of bare repositories. If you don't intend to ever work with files in the server (i.e. it's just going to be a place to push changes so they are safely stored), you could initialize a bare repository. A bare repository contains the database structure of Git, but does not have the actual files in the directory.
A standard Git repository is a directory with a hidden folder in it named .git. This .git folder contains all the various data structures that Git uses to track changes. A bare repository is essentially a folder containing only the contents of .git.
The good thing about a bare repository is that no one can work in the repository itself (since there is no working directory, just the database). This means that no one could log into S: and edit the repository themselves. Instead, they would have to clone the repository, then push their changes back to the origin. The GitGuys have a good article about why this is ideal.
Note that shared repos and bare repos are not dependent or mutually exclusive. As a general practice, if you are having a "server repo" from which you pull and to which you push, you should have it be bare, regardless of whether the project is shared.
A Non-Shared Workflow
Since it's not clear if you are sharing or not sharing and you're on a Windows environment, which I don't know about from a sharing standpoint, I'm going to give you a simple example. Using git-bash, you should be able to change directories to wherever on S: you have your repositories. Then, use git init with the bare options as described by the link above to initialize a bare repository. Navigate to where you want your repository to live on C:, and then do git clone to get a working copy.
Add a README file or something else so you can do your initial commit, and then commit and do git push origin master to push your changes to the S: repository. Once all that is done, THEN initialize the RStudio Git project. RStudio should defer to your existing configuration, and things should hopefully work.
As a new user of Fossil, I'm curious if there are any negative implications with using Fossil to store things like /etc/, /usr/local/etc files from Unix like systems like FreeBSD & OpenBSD. If I'm doing this for multiple systems, I think I'd create a branch with each hostname to track those files.
Q1: Have you done this? Do you prefer a different VCS to handle the system files?
Q2: Lots of changes have happened in Fossil over the years and I'm curious if it's possible to restrict who can merge branches with trunk. From reading earlier threads it wasn't possible but there are two workarounds:
a) tell people not to merge to trunk
b) have people clone and trunk maintainer pick up changes from their repo
System configuration files stored in /etc, /var or /usr/local/etc can generally only edited by the root user. But since root has complete access to the whole system, a mistaken command there can have dire consequences.
For that reason I generally use another location to keep edited configuration files, a directory in my home-directory that I call setup, which is under control of git. Since I have multiple machines running FreeBSD, each machine gets its own subdirectory. There is a special subdirectory of setup called shared for those configuration files that are used on multiple machines. Maintaining multiple copies of identical files in separate repositories or even branches can be a lot of extra work.
My workflow is the following;
Edit a configuration file in my repository.
Copy it to its proper location.
Test the changes. If problems occur, go back to step 1.
Commit the changes to the revision control system. Copy the
committed files to their proper location.
Initially I had a shell script (basically a list of install commands) to install the files for me. But I also wanted to see the differences between the working tree and the installed files.
So for my convenience, I wrote a script called deploy to help me with this. It can tell me which files in the repo are different from the installed files and can show me the differences. It can also install files to their proper locations.
I'm very new to the world of git (done some svn in the past) and would like some advice on trying to accomplish the following.
My current workflow is that I setup the static html files using Middleman to get the base HTML structure and styles before porting over to a Wordpress template. These static files are located at C:/git/project-name/HTMLTemplates.
My wordpress setup uses Xampp so the theme files are kept in C:/Xampp/wordpress/wp-content/themes/project-theme.
What I would like to do is have a single git repo that tracks the changes of the two different locations (HTMLTemplates and project-theme)
Is this at all possible, or do I simply create two individual repos (eg: proect-static and project-wordpress)?
No, there is no mechanism in git for this. Git assumes that all files that it manages (the "working copy") live in a single directory (and subdirectories); there is no support for managing two separate directories in in repo.
So you'll have to somehow keep everything in one directory, probably as subdirectories HTMLTemplates and theme or similar.
You could use two git repos, but I'd strongly advise against this. A single repo should contain a whole "project", i.e. everything needed to build one piece of software (excluding things like external libraries). If you split your project across two repositories, you cannot usefully branch and merge (because you'd have to do it in both repos simultaneously), you cannot easily check out old versions etc..
To solve your problem, I see a few possible solutions:
Have some build / deployment script that copies everything to the right places. You probably alread have a script that invokes Middleman, and possibly tells Wordpress to refresh its cache, so you could add it there.
Set up a symbolic link for the wordpress directory. On UNIX-like systems this is easy and commonly done. On Windows, you can create "junction points", which I believe work similarly.
Configure Wordpress / Apache to read the directory directly from your git working copy. The path should be configurable.
I would prefer the first solution; this has the added advantage that it will decouple your development environment from the server configuration. This will make it easier if your setup later changes or your project needs to run in a different environment (development on a different machine, someone else also wants to work on your project, you want to deploy to a hosted server somewhere etc.).
Note: The problem is, I believe, that your are trying to use git as a deployment tool. While many people do this, git is not really suitable for this purpose. Deployment should usually be a separate step.
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.