I'm using StarTeam 4.1 and I'm trying to use the command line version of StarTeam to checkout all the files of the folder. But for some reason, instead of checking out to C:\Installation, it checks out to C:\400\Installation. In the GUI, StarTeam clearly states that the complete working folder path is C:\Installation. If I run stcmd.exe and try to checkout a single file from the root of Installation, it says that there is no such file, while I can check it out from the GUI. stcmd.exe also does not display all the subfolders of Installation. Any idea why this might be happening?
I didn't realize that the view name was specified in the checkout command. If you do not specify a view name, the default is used. In my case, there was a folder named Installation and a view named Installation. Since I just specified to checkout Installation, it was interpreted as a view name instead of a folder, and the Installation view checked out the Installation folder to C:\400\Installation for some reason.
Related
How can I check if the core files have been modified or not in magento.
I searched on Google for this.i found following solution Quickly check if Magento core files are modified
But where to run this command and how?
Can we run this command on localhost?
Make a separate folder on your system, unzip the Magento installer file into it so you have a fresh, unchanged copy of your current version's code.
http://www.magentocommerce.com/download under the release archives tab
And then run diff in a SSH session from the command line to compare the app/code/core files of your current running version against your fresh, unadulterated copy.
diff -qrbB untainted_magento developer_mucked_magento
Using Advanced Installer. When I build and run my install project, after the install there is a folder called MyCompany (equivalent to [Manufacturer]) located within the ApplicationData folder (which resolves to C:\Users\Joey\AppData\Roaming\ on my system).
Within that particular folder is another folder called MyProgram 1.0.0 (equivalent to [ProductName] [ProductVersion].
And within that folder is another folder called install. And within that folder is a file called setup.msi with a size of 1.17MB
I have no understanding of why this file and these folders are being created. Further, after I uninstall my app, they get left behind on the system, which means my app is creating garbage.
Can someone please explain why this is happening? And also...if I can't cause this to not be present in the file system while my app is installed, how can I avoid leaving it behind on the file system after I uninstall?
Thanks.
When you are building an EXE setup file, that is the default extraction folder for the EXE, where you can find all the resources during the installation. You can change it from Media page, "Extraction folder".
It is not deleted after uninstall due a bug in Advanced Installer, you can find more details and a workaround on the forums.
I have created a PackageMaker (OSX) Installer that successfully installs two items, a main file, and a folder of files (with root), within '/Applications/[specific Application folder]/' path. Now I want to make sure the installer doesn't install the folder if it already exists (but I do want to overwrite the main file). Pretty basic, I'm sure ... but how is this best done?
Standard procedure:
You will have to create two component packages- one for the main file and the other for the folder of files.
Now in your Distribution script, you can disable the installation of second package based on the existence of the folder on the system.
Workaround:
Use your preinstall script to rename the existing folder on the system, let the new folder get installed, and then from the postinstall script, delete the newly installed folder and rename the older package back to the original name.
I have a folder that both XCode and SmartSVN both claim is "already under version control." However, when I run svn status in that folder, it says it is not a working copy. Furthermore, I cannot add or subtract the folder from the working copy in SVN, for if I add it (with or without recursion) it claims it is already under version control, and yet there is no context option for me to remove it from said version control.
Furthermore, when I check to see if there is a .svn folder in that directory, there is not.
I have tried svn cleanup in the working directory root as well as the directory in question. When performed at the root it completes with no messages. When performed in the directory, it informs me that it is not a working copy.
It is causing an annoying Obstructing - warning in XCode that is bugging me.
If anyone knows what I am talking about or has experienced the same thing please help me out!
It happens when the parent folder gets out of sync with some of its children. A possible workaround is renaming the parent folder offline (using the file system, not via svn), get a fresh copy from the repository and then bring back your modifications from the renamed folder (excluding the.svn ones).
When finished delete the renamed folder. Otherwise you might end up with broken folders:
If you renaming a project, Xcode does not remove the .svn directory in
the .xcodeproj. As a result, svn gets confused, thinking the renamed
project directory is under version control
[source]
Make sure XCode and SmartSVN are expecting the right version of you SVN installation. After last upgrade of SVN, I noticed that things have changed in how SVN handles things. Everything is now stored in the root checkout folder, and you don't have .svn folder in ech sub folder anymore.
I have recently upgraded one of our systems from Code Igniter 1.7.2 to 2.0.1.
Do do this you are required to replaced the system directory with a newer version.
The old CI system was under version control, including the system directory.
When I go to commit I get
So I go to execute the cleanup command and I get
How can I fix this?
Backup the new system directory somewhere else (outside of the SVN working copy), revert the working copy to its old state (or even do a fresh checkout if needed), delete the system folder and commit, then copy the backed up system folder into the working copy, add it to SVN and commit again.
If you just deleted the system folder (without svn remove to let subversion know) and replaced it with some other content, you could first bring back the last committed version of it and then replace or update the content with svn.
Example: Backup and remove the current system folder, do a svn update in "tada", "system" comes back. Now either svn remove it to svn add and commit the newer files or copy the new ones over it and commit the changes.