http://asawicki.info/ Graphics programming, game programming, C++, games, Windows, Internet and more...
Entries for tag "version control", ordered from most recent. Entry count: 2.
Visual Merge Tool (P4Merge)
Perforce (or P4 for short) is a commercial version control system used in many companies instead of free CVS, SVN, Mercurial or Git. It has its pros and cons, but the included diff/merge tool is definitely its good point. It's actually the best tool of this kind I've ever seen on Windows, better than free TortoiseMerge, DiffMerge or KDiff3. It turns out that this tool is also free!
To grab it, go to Perforce Downloads and download appropriate (32-bit or 64-bit) version of the P4V: Visual Client. Then install it, but from the installation components leave only "Visual Merge Tool (P4Merge)". Now you have this great, free tool in your system.
To setup it as diff and merge tool in TortoiseGit (TortoiseSVN and others are similar I think), follow instructions from article Using P4Merge with TortoiseGit. Basically, enter TortoiseGit Settings and there:
SVN in My Windows Made Me Angry
Today I had an unpleasant adventure with SVN. Although I'm now going to use Mercurial (with TortoiseHG client) for my home projects, as this whole distributed revision control systems looks quite promising, I wanted to checkout some SVN repository and it turned out to be much bigger problem than I expected.
The obvious solution is to install and use TortoiseSVN - great shell extension for Windows. Unfortunately it doesn't work in my 64-bit Windows 7. Setup succeeds, but then no new items appear in context menus for directories. I tried to install both 64-bit and 32-bit versions, two times, with restarting my computer. Nothing helped. I tried to disable read-only attribute for TortoiseSVN directory, give full permission to this directory for all users, maually run TSVNCache.exe (because it doesn't start automatically) and nothing helped. I also ensured shell extensions are successfully installed by using ShellExView. Google knows this problems, but not the solution.
So then I installed RapidSVN - a normal Windows SVN client. Such application seems even nicer for me than shell extension. But then another obstacle appeared: opening repository in RapidSVN failed with error message: rapidsvn Error: Error while updating filelist (Can't create tunnel: The system cannot find the file specified. ). I though: Fuuuu! After issues with new Windows version here come Linux-like issues with some command-line or config driven, small and independent programs that never smoothly work together. I knew it was probably because the repository I wanted to checkout have an URL starting with svn+ssh:// so the SVN client probably needs to create an SSH tunnel.
After some searching in Google I found a solution. I needed to download PuTTY package and set special environmental variable to point to the plink.exe program that, according to Google, work as SSH tunnel. This variable is named "SVN_SSH" and its value must be like "E:\\PuTTY\\plink.exe" - without quotes, but with these double backslashes! Here I was sure it had to come from the Linux/Unix world, noone other would come up with something like this :P
It seemed to work so I was a step further, but still I couldn't access the SVN repository. This time when checking out, an empty console appeared and freezed so the RapidSVN didn't go any further. I wanted to try some "easy" solution so I installed another windowed client - Qsvn, as well as console SVN client - SilkSVN, but it seemed to recognize and run this SSH tunnel and finally freeze in same situation. So after another Googling I've found this post, opened configuration file "C:\Users\MY_LOGIN\Application Data\Subversion\config" and inserted this line into it:
ssh = E:/PuTTY/plink.exe -l REPOSITORY_LOGIN -pw REPOSITORY_PASSWORD
It finally worked and I could access the repository, but it took me so much time that it made me really angry. I hope I'll live to see the day when there will be no such stupid problems with software. Meanwhile, now you can understand why do I always *very* carefully handle all errors in my code (check returned values, throw exceptions, write logs) - to always know exactly what, when, where and why went wrong, so no annoying things can happen like "context menu items don't show up and I don't know why" or "empty console window opens and freezes".