I am using Perforce as a version control system. When I create a new project in Windows and say Get Latest from the Depot a project which was written on Linux and has Linux line endings seems to have Windows Line Endings when it was downloaded to Windows workspace. I do now know who is manipulating the line endings. The version control system itself , namely perforce, or the operating system Windows.
By default, Perforce translates text files into the native format when writing them to a workspace. This is because (for example) most Windows IDEs expect CRLF formatting whereas most Linux IDEs expect LF formatting. Automatic conversion means you don't have to think about it.
If you want to manually set the line endings that a given workspace uses, change the LineEnd option in the client spec; the default local will simply match the standard format for the local platform, but you can specify unix if you want everything to be in Linux format.
https://www.perforce.com/manuals/p4guide/Content/P4Guide/configuration.workspace.line-endings.html
If you want a particular file to always be submitted and synced bit-for-bit without any formatting awareness, use the binary filetype to specify that it should be interpreted as an opaque blob of binary instead of as a text file.
Related
I have a program, ported from Unix, that uses libintl, and thus ships with .mo message catalogs. In the Unix world, those get installed into /usr/share/locale, and that's where this program will look for them. On Windows, that directory structure obviously doesn't exist. Is there a recommended location to install message catalogs in, or should I just install them alongside the program itself in C:\Program Files?
When using libintl you almost always hardcode the directory where message catalogs are located. You also do that for Unix, not just for Windows.
The difference is that for Unix you store the translations in a common directory, for example /usr/local/share/locale whereas for Windows you install the translations in the program directory.
A couple of years ago I have written an internationalized Gtk application and subsequently ported it to Windows. It will probably no longer build but I guess the libintl stuff hasn't changed since then. You can find it here: https://savannah.nongnu.org/git/?group=gibbon
I am facing a strange issue when transferring file through WinSCP FTP tool.
I downloaded a shell script file from server and made some minor modification. Uploaded this file on same UNIX server through WinSCP Tool.
When I select Transfer settings as Binary, Shell script doesn't work properly and failed. Even generated log file didn't open.
When I select Transfer settings as TEXT it worked properly.
Also, when I set Transfer settings as ASCII in File transfer through FTP command in Terminal, even it didn't work.
On the basis of above issues, I have below concerns:
Difference between TEXT mode transfer and ASCII mode
transfer?
Difference between transferring file through FTP command
via Terminal and using FTP tool like WinSCP, FileZilla, FireFTP?
I think it has to do with translation between Newlines, Carriage Returns and NL/CR combinations. i.e. Transfering a text file from a DOS machine to a UNIX machine, ASCII mode will to the proper translation, and "TEXT" mode (which I believe is really "binary" mode) will just transfer as-is, with no translation.
There's no difference between "text" and "ascii" transfer mode. These are just two names that are used interchangeably for the same mode.
There should be no difference between the text/ascii mode in GUI FTP clients and the Windows command-line FTP client.
Though the can be some implementation detail that might make a difference for a particular server.
I'm currently developing an iPhone App and my company uses TFS 2010 for source control.
We're using Team Explorer Everywhere as an Eclipse plugin to handle source control on the Mac and for other projects (like a C++ project we recently did) it works fine.
However it doesn't appear to work for this iPhone App and the main reason appears to be Aliases. It either won't store them at all or it will store them as a regular file or folder, which breaks everything.
Prior to this attempt to move to TFS I was using Mercurial in an impromptu fashion and everything just worked.
Does anyone know how to store things like Aliases from a Mac OS X machine in TFS without breaking them?
Aliases on the Mac OS are a hybrid of a sym link as well as a pointer to the source's File ID. (think of it like a pointer to the inode as well as a sym link to the full path on a traditional unix file system)
It's actually more complicated than that since the implementation of the alias structure depends on the underlying file system. This is all documented in the Overview of the Alias Manager Reference
It really boils down to how TFS 2010 is exposing it's file store to the Mac OS - my guess is that it's a SMB share and that's why your aliases are failing to survive the translation from HFS+ to NTFS storage through a SMB API. Unless you can expose the raw storage as HFS+/AFS and TFA 2010 can intelligently track the file changes, you might be out of luck and have to avoid aliases all together. Relative path sym links might be a more robust solution if you care to try that.
You'll give up all the robustness of alias reconnection on the Mac side, but control over your code changes might be more important. I'd also look into a mercurial or git bridge to TFS 2010 as they work better on the mac and might be a more acceptable middle ground.
Yes, Team Explorer Everywhere can preserve HFS Aliases. HFS stores Aliases in the file's extended attributes:
% ls -Flas alias
208 -rw-r--r--# 1 ethomson staff 69936 May 30 15:19 alias
% xattr alias
com.apple.FinderInfo
com.apple.ResourceFork
Team Explorer Everywhere will store extended attributes when the .tpattributes file is properly configured. To store extended attributes, you will need a line such as:
filename:transform=apple
When this transformation is applied, the local file's data and resource forks are combined into an AppleSingle file, which is then checked in to TFS. When you perform a get on that file from Team Explorer on another Mac computer, the Alias will be correctly preserved. On any non-Mac computer, this flag is ignored and the actual AppleSingle file itself will be downloaded.
The answer, near as I've been able to tell, is no.
Not until TFS 2011 at least, according to this
I have an old game (Westwood Monopoly CD-ROM) that only has a 16-bit installer so it won't run on my Windows 7 x64. To get around this I decided to use Inno Setup to make a new installer. The game itself is 32-bit but not LFN aware and will run on Vista/7, however the game will crash if the installer I built with Inno Setup is not run with Windows 95 compatibility checked.
There are no file or attribute differences between the folder generated by having compatibility mode on and the folder generated with no compatibility settings checked. However, the game will only run in the folder installed with compatibility mode, the game exe (Monopoly.exe) itself cannot have any compatibility mode option enabled or the game terminates whenever you try to save, load, or choose one of the computer ai player files. If compatibility mode for 95 is turned on for Monopoly.exe in the folder created without compatibility mode set for the installer, the game will load but will be unplayable for the above reasons.
My guess is that the Windows 95 setting forces short filenames to be created, while without it the game cannot find it's files because the short filename information isn't there. Having compatibility mode set for the installer is not the ideal solution since I need to be able to copy a different exe based on the version of Windows detected (Aero causes part of the screen to be cut off so I use a hex edited exe with a bigger default size).
So my question is this: Is there a way to force Inno setup to create the short filename information as it copies, or is there a way to add that with a command after it is finished (ie. repair the broken folder so the game can find its files)?
As far as I am aware, the problem is that the newer version of Windows Installer and Windows itself no longer support the use of short names. That property has been phased out of use and as of (AFIK) Vista it is flat out not used. Most modern installer technologies will give you an error if you try to include them. Have you tried looking at DosBox? That might also allow you to run it without the need for a special installer.
I have to start using CVS at my new company so that I can play nicely with the developers who are all *nix users. I happen to be a Windows Vista user and unfortunately do not have the ability to switch anytime soon. I am also not exactly a command line guru yet, so any simplified method is ideal for me.
I discovered TortoiseCVS today and it seems pretty straight forward, even though it says it is not directly supported on Vista, which worries me a little.
My questions:
Do you use CVS on Windows (Vista)?
What method do you use? (Tortoise CVS? Another option?)
Does your method get along well with repositories setup on/by *nix machines?
Any other advice for the noob? (Thanks)
I know many people who required a gentle introduction to cvs and ended up using WinCVS with no real difficulty. I know many others who are using the cvs client in Eclipse. This usage includes projects which are not otherwise managed by Eclipse. As for myself, I stick to the command-line myself because I feel the lack of GUI abstractions helps me to always understand exactly what CVS is doing. All three solutions work well on Vista, 32 and 64 bit. Our shop uses Mac, Linux, Solaris, and Windows, with the server on a Linux machine, and we never have any problems with compatibility.
There's one issue you should be aware of regardless of your choice of cvs client for cross-platform goodness, though. Most cvs clients convert between Unix newlines (on the server) and Windows newlines (on the client) by default. You should understand that this conversion is happening and be aware of the consequences.
This conversion will cause real problems if you try to commit a file with Unix newlines. So, you need to avoid, for example, copying files from a Unix repository to your Windows box, editing them, and committing them unless you've done the newline conversion. We had some real problems with this in my shop, and I instituted a strict policy that people should only communicate files between machines by committing them to CVS. Never, for example, by email, shared network directories, etc.
If your CVS repository has any binary files, some may not have been properly tagged as binary files. In *nix-only shop, nobody would notice, as the binary flag won't affect most binary files. But in a cross-platform shop, the binary flag routinely affects how cvs treats files, since it will disable any attempts at newline conversion. Typically, any file which was committed from a Unix box will be correctly represented in the repository, so you can fix the problem on the Windows end by merely changing the tag and re-updating. I.e.,
cvs admin -kb file
cvs update -A file
There are some other avenues you can take to interact with your *nix bretheren.
Install VirtualBox and a distribution of Linux so you can natively run the same toolset.
Install VirtualBox and a copy of Windows XP, which is known to work with TortoiseCVS.
You can find VMWare appliances pre-loaded with a linux distribution, which you can import into VMWare Player or VirtualBox. From there you just need to connect up to your shared drive the same way that they do.
Please note that CVS is no longer being maintained. You should really be moving to SVN, git, or some other version control system.
If you're using an IDE like Visual Studio or Eclipse, you should look for the appropriate plugin that integrates with your environment. Those might be better supported (though TortoiseCVS is likely just fine, even if the developers don't want to make any claims).