I want to move my menu settings of TGit from one PC to other, but cant find them on HDD. Is it in registry somewhere? I'm on Windows 7 if that is important.
The last comment of TortoiseGit Issue 1013 seems to show those entries are in:
HKCU/Software/TortoiseGit/
Marco Eckstein points out however in his article:
There are some values which should probably never be shared between different TortoiseGit installations, e.g. CurrentVersion.
There are some values which you may not want to share between installations, e.g. those beneath the subkey HKEY_CURRENT_USER\SOFTWARE\TortoiseGit\History if you have one installation at home and one at work.
Some values will only be created when you change the configuration to be different then the default.
E.g., a new installation will not have any values for context menu configuration. If you would use a .reg file on another new installation, that would not be a problem. But if the other installation would already have values for non-default configuration, you would not overwrite the non-default configuration with the default configuration by importing a .reg file.
His script Set-TortoiseGitSettings.ps1 will help set the right configuration across workstation.
Related
I have a custom screen step displaying checkbox options for web.config specific to each environments (DEVINT, QA, Stage,Prod) as part of MSI installation.
Once the user selects QA as option then the web.qa.config file is renamed to web.config file
After the complete installation, I see that there are other web.config files ( web.DEVINT.config,web.stage.config,web.prod.config) still present in the folder.
I want to remove the other web.config files web.DEVINT.config,web.stage.config,web.prod.config
after the installation is completed.
Can anyone help me to resolve this issue.
Thanks & Regards,
Santosh Kumar Patro
A RadioBox would seem a better choice then a Checkbox since I would imagine the choices are mutually exclusive. Use the property associated with the control as conditions on the component so that only one of them gets installed.
Windows Installer will complain (ICE Valication) if multiple components install the same key path. What I do to get around this is to make the keys paths go to a subdirectory such as Configs\Web.LifeCycle.Config so that each is unique. Then I use the DuplicateFile table to clone that file to the real directory \ web.config path. The downside is I deploy a subdirectory/file that isn't needed but the upside is I can use it to quickly know what was picked and have a backup of the file to compare against in case someone goes and modifies the real web.config.
In limited scenarios I use AppSearch to autodetect the life cycle instead of showing a UI at all.
I store all SSIS packages in Subversion repository, their configuration files as well. Configuration file almost always stored in the same folder where package is.
Problem is - SSIS seems to always store path to configuration file (the one saved in the package itself) as an absolute path.
When someone else checks out folder with the package in the location different from where I had on my development PC the configuration file is not detected (because my absolute path is stored and it doesn't exist on the other developer PC). So another developer has to remove this configuration and add it again from where it is now on his local hard drive. Then changed package is saved which will cause new version to be committed. When I get that version from SVN it will no longer match local path on my PC.
On a related note: another developer may want to change values in configuration file as well. If I later get the latest version of everything from SVN package will no longer work on my PC.
How do you work around these inconveniences?
Another solution is to save your configuration in a database with an environment variable as the first configuration to tell it what database to look in, that's what we do. We have scripts to populate ssisconfig for each server in our source control, but the package uses the actual table data for the database in the environment variable we are using.
Anyone who has heard my SQL Saturday presentations knows I don't much care for XML and this is one of the reasons. A trick to using XML configuration with varying locations is to use an environment variable (indirect configuration) to direct SSIS where it can look for that resource. The big, big downside to this approach is you'd generally need to create an environment variable for each set of configuration files or have a massive, honking .dtsconfig file which becomes painful for versioning.
The option I prefer if XML configuration is a must is that the "variableness" is removed. Developers and admins get together and everyone agrees "there will be a folder everywhere SSIS is done to hold configuration files and that location is X" and then it's just a matter of solving for X. At a previous job, we used D:\ssisdata\configs
#HLGEM's approach of a table for configurations is hands down my favorite approach to SSIS configuration (until you get to 2012 and their project deployment model where configuration is an entirely different animal)
I add a folder called "config" under my projects folder, add it to source control and mantain the config file in this folder. You can also add it to the SSIS project if you like.
I think its a good solution because everybody can have this folder and dowload the config file.
When the package is deployed it will read the config file from where you inform in the deployment manifest so this solution wont impact your development
I try to install/run emacs on a Win7 64-bit machine after using it for years on a WinXP 32-bit machine and run into a problem I do not find any help for in the documentation or on the web.
Symptom:
when starting runemacs.exe for the first time it creates the file
*C:\Users\USER\My Documents.emacs.d*
as one would expect (for my administrator as well as for my user account)
and comes up operational
from the second start of runemacs.exe it breaks in the startup phase,
displaying the scratch buffer, ringing the warning bell and displaying in
bottom line the error:
File exists: c:/Users/USER/My Documents/.emacs.d/
buffer messages specifies:
make-directory: File exists: c:/Users/USER/My Documents/.emacs.d/
if runemacs was called with a file to open, i.e. because the file type was
associated with it and the file was opened to edit, the file is not open
and ready to be edited, but a file can be opened via the menu File->Open File...
but my configurations in the file
C:\Users\USER\My Documents.emacs
are not loaded
My goal:
I want to regain the way I used emacs on the old WinXP 32-bit system:
click a file associated with emacs, get it opened and ready for editing, get my configurations in .emacs loaded automatically, i.e. work with emacs seamlessly.
Checks done and failed attempts to fix this:
I tried the following newly downloded versions of emacs
emacs-23.4-bin-i386.zip
emacs-23.2-bin-i386.zip (the one I used on the WinXP)
I had the emacs directory containing the directory stucture (bin, etc, ...)
located at:
C:\Program Files (x86)\emacs-23.4\ (my preferred location)
C:\Emacs\emacs-23.4\
in the download directory, where I originally extracted it
My HOME variable points to:
C:\Users\USER\My Documents (default)
C:\Users\USER\My Documents\ (tried)
My PATH variable contains:
C:\Program Files (x86)\emacs-23.4\bin (default)
or the corresponding other locations which I tried
The ownership and permissions of my C:\Users\USER\My Documents.emacs.d
look OK:
owner is the USER (administrator or standard_user)
permissions grant Full Control
Having originally installed emacs to *C:\Program Files (x86)\emacs-23.4*
using the administrator account, I also tried to use user account installation
instead (to check for some non- obvious parameter/access permission not set
right if the admin account is uses for setup)
For the runemacs.exe executable I manually set the compatibility settings to
Windows XP (Service Pack 3)
default setting after unpacking: no compatibility setting enabled
I removed the private configuration file C:\Users\USER\My Documents.emacs
(inherited from my XP installation) to check whether it produces a screw-up
All that did not change a bit of the described symptom, i.e. either I screwed up
in testing the above and missed a particular setting which should work, or I am looking into the wrong direction...
It is still unclear to me whether this has anything to do with:
W7 64-bit vs. XP 32-bit
environmental parameter screw-up
emacs configuration (.emacs, .emacs.d) screw-up
general stupidity (of me ;-)
... and why is it has emacs a problem with it in the first place, that the .emacs.d directory already exists... That should be the standard case...
Any help and wisdom much appreciated.
First of all, nice question. The details and listing of what you've already tried is helpful.
Some points:
Don't have spaces in key paths (Emacs, and %HOME%). Generally, things work
fine. But when things break it's often hard to debug and trace back to the
fact that some package author didn't take spaces properly into account.
Set a HOME environment variable to your %USER_PROFILE%. Make it
%USER_PROFILE%/home if you must, but I use the former.
Start by running emacs without any customization.
runemacs -Q
When that works, add your customizations one at a time.
n.b. This answer is not relevant to the original question (which was about Windows), but may be useful to Unix users searching for this error message
You will get this error also if emacs does not have the correct permissions on the .emacs.d directory.
Check it
ls -ld $HOME/.emacs.d
And make sure the user you are running under has rwx permissions!
I got similar problems when I installed the new version of emacs on a new installation of the ubuntu 12.10. I get the problem fixed by chmod 777 .emacs.d, that is, as the previous post pointed out, the emacs does not have the access right to .emacs.d directory. Hope this help.
This is exactly the same case as this one, but with Hg instead of SVN. I have MercurialEclipse installed, and I have changed the password of my remote repo. Now when I synch it fails.
I have not found any conf file in "C:\Documents and Settings\%USER%\Application Data..." about Hg.
I have deleted the .keyring eclipse file and restarted but still fails.
Eclipse 3.6.1 with MercurialEclipse1.6, on windows Vista
In reply to pyfunc (thanks):
I found an entry like this in .hg\hgrc:
[paths]
default = https://user:oldpassword#bitbucket.org/myprojectpath
so I changed to the new password and restarted eclipse, but still I get 'authorization failed'...
I finally found out a way to achieve this. If I select "Synchronize With" I get a dialog and I am able to insert the good values, so now I could synch!
This does not explain why changing values in .hgrc didn't work, but at least is solved now, although it would be nice to find out about the details...
Typically that is stored in .hgrc file. That is the user configuration file stores in the HOME directory. You should be able to change the password there.
As per the man page of Mercurial, there are some suggestions about the location of config file on windows.
1. <install-dir>\Mercurial.ini
2. HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial
3. C:\Mercurial\Mercurial.ini
4. %HOME%\Mercurial.ini or
5. %HOME%\.hgrc or
6. %USERPROFILE%\Mercurial.ini or
7. %USERPROFILE%\.hgrc
it could also lie in /.hg/hgrc
Finally found the config file after some digging... it's in ${workspace_location}/.metadata/.plugins/org.eclipse.core.runtime/.settings/com.vectrace.MercurialEclipse
If you close Eclipse, open this file, and delete just the lines at the bottom starting with repo_, the settings you have saved for that repository (including credentials) should be cleared the next time you open Eclipse. You'll probably want to make a backup of the file just in case.
Since these credentials override whatever you have in your hgrc, deleting these should allow the repositories to authenticate with your global settings. You won't necessarily see the credentials in the username/password fields in Eclipse, but if you click Next/Finish anyway, it should work fine.
I'm using Eclipse and the Subversive for SVN control, in Windows. I've also installed TortoiseSVN. The SVN repository I'm using is utilizing a svn+ssh scheme, and there is no way to change that.
Now, there's a file in %APPDATA%\Subversion\config that I need to edit to perform SVN interaction in Eclipse without typing in the password every time. The line in this config file reads now (default):
ssh = $SVN_SSH ssh -o ControlMaster=no
I've read a bit on the web that the $SVN_SSH is an environmental variable in Windows, and in this case it points to TortoiseSVN\bin\TortoisePlink.exe, which is correct.
What is the additional parameteres to append this config to make it take my private key? I've updated the "authorized_keys" file on the server (in my .ssh folder) with my public keyphrase, and I've tested and confirmed that logging in to the SVN server outside Eclipse works like it should with my private/public key pair.
The problem here is to make it all work inside Eclipse, and it's quite frankly a small nightmare :/ If anyone has experienced the same, or knows any remedy, I'd appreciate any help.
If you set the 'SVN_SSH' environment variable the rest of the line is ignored, so you should either replace '$SVN_SSH ssh' with the path to the program, or move the required arguments to the end of the SVN_SSH environment variable.