We are using VSS for version control (changing to another version control system is not an option right now), and are occassionally running into issues where a file has been completely deprecated with its functionality split into other new files. For historical archival reasons we need to keep those files in the version control sytem. Is there some way to clearly mark them as deprecated and no longer used?
Delete the files?
Deleting does not remove the historical versions - there is a separate command Destroy to do that.
Related
I'm currently working with InstallShield to deploy a .NET Winforms app. I am new to InstallShield and have not enjoyed the learning curve. The Winforms app has three related DLL's which are not getting updated during a minor upgrade. For a minor upgrade I am changing the version from 1.0.001 to 1.0.002 for example. The package code is being changed for each build automatically.
I have tried adding the dll's to the [INSTALLDIR] and setting the property to "always overwrite". For some reason this causes the upgrade to also not update the main exe.
Tried changing the product code to force a major upgrade. This installed a new version alongside the old version, but the new version still had the old dll's.
Tried changing ReinstallMode from "omus" to "vomus". This had no effect at all.
Tried using REINSTALL=ALL, REINSTALLMODE=vomus. This did not update the dll's and also caused new installs to fail with message that application "is not marked for installation".
Tried changing the version from 1.0.00x to 1.1.00x. dll's still not updated.
I notice that when I view properties of these dll files, they have File Version = 1.0.0.0 and Product Version 1.0.0.0. Do I need to manually increase these versions in order for InstallShield to recognize that they have been updated?
Use one component per file and set each file to be keyfile in its own component. This avoid all sorts of component referencing and file replacement issues. Be aware that multi-file assemblies must share the same component as they are intended as one "atomic" file system unit.
In addition you must also increment the version number for each build or set REINSTALLMODE to emus instead of the default omus. Never use amus.
My advice: go with the file version updates - it is much more reliable. Like you state the File Version is used, it must be incremented. I like to auto increment the build version number (last digit). It has been a while, but I think you just replace the number with * and it auto increments. I think you can do this from the Visual Studio project property view.
Maybe read up on the file versioning rules as well. Essentially versioned files are version compared, and for unversioned files the create and modify date stamps are compared and the file is replaced if it is unchanged on disk. More sample info.
Remove the "always overwrite" flag you enabled for all the files you enabled it for. This flag may work poorly with patches if you ever need them and also with other features.
When a major upgrade creates two side-by-side installations it hasn't worked. What you are left with are two different products installed at the same time. There is good inline help in Installshield itself with regards to how a major upgrade is set up. Which version of Installshield are you using? The version bundled with Visual Studio may not feature this help material.
A note on major upgrades and "reverted files":
A warning on a classic major upgrade issue: be aware that changed, unversioned files not set to be permanent on original install may be uninstalled during a major upgrade and then reinstalled yielding the impression that they have been replaced, but they are actually deleted and recreated. These are typically important settings files like XML files or similar - and people struggle with this issue a lot. Major upgrades are essentially a sequence. The old product is uninstalled, and then the new one is installed or vice versa. In the former case the files may be uninstalled first and then recreated. This does not happen in the latter case if component referencing is done right because the files that are matching between products are not uninstalled, but retained and then overwritten if need be (according to the file replacement / versioning rules).
I have been using XCode with subversion for some time now, no problem was caused when I was using it as a single developer (I was using 2 commands only, commit and add).
But now I have to share the code with another developer (who has never used any kind of version control) and integrating/merging the code has become a nightmare. No problem occur when we are integrating/merging .h/.m files but as soon as it comes to ".nib", "xcodeproj" and ".xcdatamodeld" files, we really don't know what to do.
Whenever we try to merge "xcodeproj", project was getting corrupt and merging ".xcdatamodeld" was kind of impossible for us.
So I was wondering if someone can share his/her experience on how to effectively use subversion/git/mercurial with XCode 4.0 in multiuser environment? or share a link, which can explain how to use subversion effectively in multiuser environment.
Thanks.
Are you doing this using Subversion? For 90% to 99% of the files in your repository, the standard Subversion workflow of checkout, edit, commit works well. However, for some types of files such as JPEGS and GIFS simply don't merge well. In this case, you'll have to do it the way we use to in the old SCCS and RCS days: Before you can edit and commit a file, you must lock it.
Locking a file prevents others from editing the same file and committing changes while you're doing your work on the file. It's crude, but it works. In Subversion, you can always lock any file you're editing, but if the file has the property svn:needs-lock on it, it will be checked out as read-only. You have to lock the file before editing it to make it writable, and you're not allowed to commit the file unless it is locked.
So, for those files, set the svn:needs-lock property on it.
You can automatically set this property on all newly added files (depending upon suffix) via setting the auto-properties in your Subversion client configuration.
And, if you really, really want to make sure that all .nibs and xcodeproj and all of the other flies of these types have svn:needs-lock set on them, you can use my pre-commit hook which will prevent these files from being committed unless this property is set.
There is no failsafe way to merge these kinds of files that I am aware of. So you will have to
try to ensure that only one person is changing these files at a time. That won't work always, so just log what you changed in the file with the commit message. Then if there is a conflict, you can manually resolve it by taking the version that changed more of the file and redo manually what the other person did.
That's normally not a big deal, like adding a new source file to an .xcodeproject, or changing the alignment of an element in a .nib. It's becoming a problem if your project is huge or your nib is containing the whole interface. For it to work well (which in practice it does), you need to split up your projects into sub-projects if they grow too huge.
I had the same problem with 2 other developers Xcode with git. Unfortunately, Xcode project files are an XML file, tracks file included in the project as well as setting. I'm not certain, but I think .nib files are also XML files as well. Someone can correct me on that.
Git did a great job at merging the Xcode project file, and never really had any problems with our *.nib files either. The only time we did have a problem is when we both added/removed files with the same names, or someone did a lot of heavy removing and adding of a lot of files.
The only way we solved this was to have each other push ann pull as soon as we added/removed files. So that way the person had the latest files, and didn't add them in their own repository then pull the latest commit which had the same file in it. Or they work adding changes to a file that was removed or renamed.
That is the best solution we found, as soon as we added or removed a file have everyone else in the team pull. Not a great solution btw. However, you should be committing often anyways.
I am the only developer of a software project. I did not use any version control until now. I know I can put the last version of the project under version control. The question is whether it is possible to put older versions and branches of the project under version control. If it is possible, how ?
which version control software should I use ? (I am using Visual Studio 2008)
Edit: I have almost all previous versions.
You could do it, assuming you have copies of the older revisions that you want to put into source control (you can't magically make them appear, of course).
What I would do is take the oldest version, put it somewhere, and commit the folder to your source control (this would become Revision 1). Then, take the second-oldest version, overwrite the first version on your hard drive with that, then check in again (this becomes Revision 2 in source control). Repeat, overwriting with the next-newest revision each time until all of the versions you want are checked in.
There are good, free version control systems available. I use SVN (with the TortoiseSVN shell add-on), and I'm quite happy with it. CVS is alright too, but gets very slow as projects get large.
Which VCS you should use is really up to you. I'd recommend Mercurial as it is a very good distributed VCS and runs rather well under Windows. I don't know what VS support but you may want to use a supported VCS (which probably means Subversion I guess). There is TortoiseHg available there as well.
If you have all previous versions, you can import them manually, one after the other to get to the last one then work from that.
I have created an installation package using Wix which installs a Windows service on the user's machine. Currently, the files are being installed to [%ProgramFiles%\APLICATIONNAME].
Is this a future proof way of structuring an installation folder?
Should I be installing to [%ProgramFiles%\APLICATIONNAME\VERSION_NUMBER] instead?
Any recommendations would be greatly appreciated.
Thanks,
Arnie
Update:
Side-by-side installation of different versions will not be supported.
Version specific folders are no good. What you need to do is make sure all subsequent installers upgrade properly over the previous versions so that different folders are not required.
You may want to do something like ProgFiles\App 1.0 using the major and minor version number if you want to allow side by side installs of different versions. But with all of this it should ultimately be up to the user where the installed files end up.
As an additional note, if you are storing application data in the registry of the %AppData% folders then those are sensible places to use versioned folder names,
eg. %AppData%\Manufacturer\Application\1.0 and HKCU\Manufacturer\Product\1.0 or whatever.
We use this with a folder for each major release, this way if we decide to change our registry structure, rework data file formats, etc we only have to ensure compatibility between minor releases. Major releases can use a separate procedure to help the user migrate from a 2.x to 3.x release.
If side-by-side installation of different versions will not be supported I think [%ProgramFiles%\APLICATIONNAME] is good enough. However personally I prefer [%ProgramFiles%\COMPANYNAME\APLICATIONNAME].
So you know a lot of Mac apps use "bundles": It looks like a single file to your application, but it's actually a folder with many files inside.
For a version control system to handle this, it needs to:
check out all the files in a directory, so the app can modify them as necessary
at checkin,
commit files which have been modified
add new files which the application has created
mark as deleted files which are no longer there (since the app deleted them)
manage this as one atomic change
Any ideas on the best way to handle this with existing version control systems? Are any of the versioning systems more adept in this area?
Mercurial in particular versions based on file, not directory structure. Therefore, your working tree, which is a fully-fledged repository, doesn't spit out .svn folders at each level.
It also means that a directory that is replaced, like an Application or other Bundle, will still find it's contents with particular file names under revision control. File names are monitored, not inodes or anything fancy like that!
Obviously, if a new file is added to the Bundle, you'll need to explicitly add this to your repository. Similarly, removing a file from a Bundle should be done with an 'hg rm'.
There aren't any decent Mercurial GUIs for OS X yet, but if all you do is add/commit/merge, it isn't that hard to use a command line.
For distributed SCM systems like git and mercurial shouldn't be a problem as Matthew mentioned.
If you need to use a centralized SCM like Subversion or CVS, then you can zip up (archive) your bundles before checking them into source control. This can be painful and takes an extra step. There is a good blog post about this at Tapestry Central:
Mac OS X bundles vs. Subversion
This article demonstrates a ruby script that manages the archiving for you.
An update from the future:
If I recall, the problem with managing bundles in SVN was all the .svn folders getting cleared each time you made a bundle. This shouldn't be a problem any more, now that SVN stores everything in a single .svn folder at the root.
Bringing this thread back to daylight, since the October 2013 iWork (Pages 5.0 etc.) no longer allows storing in 'flat file' (zipped), but only as bundles.
The problem is not the creation of version control hidden folders inside such structures (well, for svn it is), but as Mark says in the question: getting automatic, atomic update of files added or removed (by the application, in this case iWork) so I wouldn't need to do that manually.
Clearly, iWork and Apple are only bothered by iCloud usability. Yet I have a genuine case for storing .pages, .numbers and .keynote in a Mercurial repo. After the update, it blows everything apart. What to do?
Addendum:
Found 'hg addremove' that does the trick for me.
$ hg help addremove
hg addremove [OPTION]... [FILE]...
add all new files, delete all missing files