I've been using Subversion for code control with TortoiseSVN to interface with the server for the past few months, and in general it's been going great! However, occasionally my FoxPro IDE will change the case of a file extension without warning where "program.prg" becomes "program.PRG") TortoiseSVN apparently takes this to mean the first file was removed, becoming flagged as "missing" and the second name comes up as "non-versioned", wreaking havoc on my ability to track changes to the file. I understand that Subversion has it origins in the case-sensitive world of *nix but, is there any way to control this behavior in either Subversion or TortoiseSVN to be file name case-insensitive when used with Windows?
Unfortunately, Subversion is case-sensitive. This is due to the fact that files from Subversion can be checked out on both case-sensitive file systems (e.g., *nix) and case-insensitive file systems (e.g., Windows, Mac).
This pre-commit hook script may help you avoid problems when you check in files. If it doesn't solve your problem, my best suggestion is to write a little script to make sure that all extensions are lowercase and run it every time before you check in/check out. It'll be a PITA, but maybe your best bet.
Windows does support case sensitivity, but you must send it the correct POSIX flags on CreateFile from the Windows API! A registry key may need changed (SFU/Tools for Unix and Ultimate Windows 7 has this registry entry already set so windows supports case sensitive file names).
Windows is designed off of Unix, but things such as Explorer.exe and other programs are designed to disallow case sensitivity for backwards compatibility and security (mostly when dealing with dos executing notepad.exe vs. NOTEPAD.EXE, where all caps is a virus or malware).
But Vista+ has security attributes which makes this obsolete.
TortiousSVN just doesn't support passing this posix flag while making and renaming files.
I use TortoiseSVN with VFP, and it mostly-seamlessly handles the case flipping. The only time it doesn't is if I have the file open in the IDE when I try to do the commit: the file lock VFP holds confuses it. Is this where your problem comes in, or are there other issues?
I did a presentation at FoxForward last year about using VFP with Subversion: most of the presentation dealt with the command line, but there are a couple of slides at the end that have links to tools that help you work with Subversion in VFP. http://docs.google.com/Presentation?id=dfxkh6x4_3ghnqc4
Kit, you comment above that VFP's binary-based source files are tough to work with in Subversion. The link I gave above mentions a couple of tools to make it easier, but the one I work with is Christof Wollenhaupt's TwoFox utility -- it converts a VFP project to text-only. You have to run it manually, but I don't have a problem with that.
http://www.foxpert.com/docs/cvs.en.htm
I believe the random upper and lower case on the extensions isn't random at all.
I remember testing on this. If you modify a program from the project manager.
By clicking on the modify button let's say. And then save the changes the extension is lower case. If you do a modify command from the command window and save the changes the extension is upper case. Apparently the coders at Microsoft didn't worry about the extension case being the same.
TortoiseSVN has a Repairing File Renames feature. It requires manual intervention and it actually issues a file rename operation to be committed but nonetheless addresses current use case by keeping file history.
Nope you sure can't. SVN is case-sensitive unless you were to rewrite the code somehow ... it is open-source.
We had a similar problem and I found a better solution than the ones exposed here, so I'm sharing it now:
For commits done manualy, now TortoiseSVN fixes the case of the file names automatically: it renames the local files to match the case of the versioned files (just by opening the commit window in that path), so there should be no problem with that.
For automated commits you cannot use TortoiseSVN, as it requires you to manually confirm the commit (it opens the commit window with a specific message, but you still have to click ok). But if you directly use Subversion (svn) to make an automated commit, then you will have the case-sensitive issue on that commit, as Subversion is still case-sensitive...
How to solve this for automated commits? Well, I tried a mixed approach: creating a batch file called FixCaseSensitiveFileNames.bat that you may call passing the path you want to fix before the commit, for example: call FixCaseSensitiveFileNames.bat C:\MyRepo. The batch file opens TortoiseSVN for a manual commit, and that automatically fixes the file names, but then it closes the commit window after a predefined pause, so you can continue with the automated commit with the case-sensitive file names already fixed. The pause is emulated with a local ping, and you can change the duration by changing the -n argument, which is the number of tries. If you don't make a long enough pause, it exist the risk to close the TortoiseSVN window before it makes its magic fix. Here it is the code of the batch file:
#echo off
REM *** This BAT uses TortoiseSVN to fix the case-sensitive names of the files in Subversion
REM *** Call it before an automated commit. The Tortoise commit fixes this issue for manual commits,
REM *** so the trick is opening the commit window and close it automatically after a pause (with ping).
REM *** %1 = path to be fixed
start TortoiseProc.exe /command:commit /path:"%1"
ping localhost -n 10 >nul
taskkill /im TortoiseProc.exe
This totally solved the issue for our automated daily build process. The only problem I see is a window will open for a few seconds, which was not a problem for our daily build, but if that is a problem for you there could be workarounds too...
Related
My primary development environment is within Windows but for Git, I try to mainly use the command line for doing most things and occasionally use TortoiseGit for others (such as viewing viewing logs or rebasing). Usually when switching branches, there are no problems when it's removing and restoring files. But certain programs lock these files (e.g., editing CSV files in Excel) which causes minor issues when switching branches.
If switching from the command prompt and a file is locked, it'll simply notify you that it was unable to unlink the file and ask you if you want to retry. This will give me a chance to close the program that has the lock and let it try again.
switching from command prompt
However, if I were to switch branches through TortoiseGit, it will have the error but will act as if the response was N and finish up leaving the files in their current state. It gets a little annoying as I have to go back and manually revert the files. I'd rather have it wait and ask me to try again, like it usually does with other actions.
switching from TortoiseGit
Is there any way I can force TortoiseGit to halt and ask me to retry unlinking the file when switching branches? Or is this just not a feature of TortoiseGit?
Up to TortoiseGit 2.2.3 the yes/no question wrapper (GIT_ASK_YESNO) was not implemented. Starting with 2.2.4 this will be supported, however, I don't know why after an "error" success is reported by git.exe.
Recently switched jobs and with it switched source control from TFS to SVN, which is new to me.
In TFS there was an option to disable automatic checkout of files when you started typing in them. It's enabled by default and a lot of users like this behaviour, but I prefer to know for certain what's being changed before committing. A personal thing.
VisualSVN auto-checkouts by default. Is there an similar option to turn it off? I can't seem to find out in the settings.
"Automatic checkout" term in SVN and in TFS worlds has different meanings, as far as I see.
In Subversion, checkout relates to svn checkout operation which gets a working copy from a repository. In TFS it looks like the term somehow relates to automatic locking mechanism.
If you want a file to be locked automatically when you start modifying it in Visual Studio (with VisualSVN extension installed), see the KB article "Lock-Modify-Unlock Model with VisualSVN". I also suggest reading the SVNBook chapter "Locking".
Generally speaking, you can set svn:needs-lock property on files. The property instructs client which files must be locked before editing. After applying svn:need-lock to a file the file gets read-only attribute. Before editing the file must be explicitly locked by the user. After committing the lock is released by default.
Short answer: I don;t think you can do this without becoming very unpopular.
I think you should read up on the SVN redbook's description of how SVN works, especially the versioning models
In your environment, everyone wants to be able to modify any file locally and then send their changes to the server, merging changes with colleague's changes if necessary. This approach works well if 2 people are not changing the same files all the time, which is typical of most dev shops.
The old TFS/VSS model of checkout a file to work on it is pretty obsolete today - the more 'optimistic' approach where you assume you have exclusive access is much more productive. (as usual its easier to ask forgiveness if it goes wrong than ask permission every time)
Your main problem is that you cannot mix these models - if your colleagues are using the merge model, then you have to as well. You cannot lock a file and expect them to still be able to change any file anytime.
Now, there are tricks you can use to prevent yourself from modifying files you never meant to - I'm not sure of VisualSVN but TortoiseSVN (awesome tool) can run client hooks - ie you can write a program to run on every checkout, and that program can be as simple as setting every file's read-only flag. Whether this is god enough for you is another matter.
Personally, I would get used to the idea of change whatever you like whenever. If you accidentally edit a file, you can see the change indicator (AnkhSVN turns the file icon orange for changed files), and its easy to 'svn revert' changes you didn't want to make. Also SVN lets you see diffs really easily, especially on commit - double click the files in the commit dialog. The productivity gains from being able to work without the tools getting in your way (as I found with TFS continually pinging at me as I tried to edit a file) are huge. The SVN tools are really good to let you "ask forgiveness" so you don't need to run in the crappy old TFS way now you've upgraded to something better.
The other advantage is that this applies to files that are not in a Visual Studio project, if you've ever had a project file that was edited outside VS (eg a generated WCF client stub) then you will appreciate how SVN works - never again will you do a full commit and find that TFS has conveniently decided that your changed file wasn't changed and so didn't need to be committed!
I've been using Vim (MacVim) exclusively for months now, and I love it. Before using Vim though, I used Coda (I'm on OSX), and the one thing I miss about Coda is the way it marks my files for publishing via FTP whenever I edit them. I can then choose to upload the modified files single files individually, or to publish all of them in one go.
Is there anything that will do this or similar in Vim?
I'm aware netrw can edit directly over FTP, but I have all my sites running locally as mirrors of the online sites, so I need to edit locally and publish files remotely as and when I need. I've Googled for solutions but can't find anything.
I'm far more productive in Vim while in the editor, but having to open up an FTP program and hunt and peck to copy across files as I edit them seperately is a real pain, and makes me less productive overall when working on websites when compared to working in Coda.
Any suggestions welcome :)
Transmit, Cyberduck and YummyFTP (the ones I know) all have their own version of "automated folder syncing" where you work locally and any modified files are uploaded on change: you setup an "observer" and never have to hit a special button or shortcut again.
If you want to only use MacVim you could write a little command that uploads the current file on save: a script that would use the current file's path to construct an scp command. But this doesn't seem very portable/practical to me. It appears some people have already written something like that: here and there.
The right way is (not only in my opinion) to:
have everything under some kind of VCS like Git, Subversion or Mercurial or whatever floats your boat
write your code in a local clone/checkout and test the hell out of it on a local server
commit only working code
push milestones to a staging server used by you and your clients to test everything, this part can be automated via a post-commit hook or something like that
deploy only validated changes on your production server.
All the aforementioned Version Control Systems can be used directly from Vim's command line with :!git commit or :!svn update… If you need more abstraction, Fugitive (Git-only) or VCSCommand (multi-VCS, my choice) are here to help.
On your loss of productivity due to uploading files: I think it's very normal because you essentially perform very different tasks with very different neurological needs. This speed bump can also be experienced when previewing a layout change in your browser, looking up a color in Photoshop or any other similar task. I don't know of a way to pilot Photoshop, Chrome's dev tools or Outlook from within Vim and I don't think such a gizmo could reallistically exist so you will probably have to bear with it.
You can try git-ftp - a git based command line ftp client. Then you can manage your project as a Git repository, and git-ftp will only upload the files marked with Git - and only if they have changed.
The downside is that you are going to have to learn Git - and that's a bit overkill for what you need.
The upside is that you are going to learn and use Git.
I have since stumbled upon a Vim plugin which works with Transmit (which I happen to use as my main FTP client) and allows me to upload the current file to the server with a simple keymap (Ctrl+U) as I edit.
This strikes a nice balance between being a very simple solution, and one that does enough of what I need to improve my productivity significantly.
Any more suggestions are still welcome!
Here's the scenario I'm currently running into:
Programmer A (Using a Mac Version of Dreamweaver) edits file client.php and commits that file to the production branch of Project Foo's repository
Programmer B (Using a Windows Version of Dreamweaver) edits file client.php to fix a bug in the that file. He then does a cp clientInfo.php ../prod-branch/clientInfo.php to take that bug-fix from his working copy to the production branch.
Programmer B then does an svn diff ../prod-branch/clientInfo.php to see what svn says his changes were only to discover that svn says he's changed every line in the file!
Now, this is what I believe is happening:
When the file gets edited by Mac, Dreamweaver on Mac replaces all the Windows newline characters with Mac newline characters so that it's readable in Dreamweaver. In short, Dreamweaver has altered every line in the file. Now, once the commit is done, svn sees that every line of the file has changed and marks this fact down. When the windows programmer makes a change and the newline characters get changed again, svn thinks that, again, every line has changed.
My question is this: How can we prevent this from happening? I know there's no way to undo the damage that's already been done, but I want to prevent this from happening in the future.
You need to use the "svn:eol-style" property on all text files. Usually setting it to "native" will suffice
Dreamweaver has an option to set which line break type it uses. Edit (on Mac: Dreamweaver ) -> Preferences, Code Format, Line break type.
Get your users to have the same setting, and things should play a little better together. It would be better, of course, if you can set your source control to ignore line break differences.
svn:eol-style is a property that can be set centrally in the repository and should sort out your problem.
Check out the chapter on New Line Sequences in the Subversion book.
The solution to this problem is the svn:eol-style property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are:
TortoiseSVN has a feature to set the file dates to the "last commit time." The default is false.
This would be nice to use for the purpose of robocopy install scripts. If one developer does a robocopy install of a website, when I update my repository my file change dates aren't the same as his, so if I try to do an install, the dates are all different and robocopy thinks it needs to update every single file.
However, TortoiseSVN's docs provide this warning: (emphasis mine)
This option tells TortoiseSVN to set
the file dates to the last commit time
when doing a checkout or an update.
Otherwise TortoiseSVN will use the
current date. If you are developing
software it is generally best to use
the current date because build systems
normally look at the date stamps to
decide which files need compiling. If
you use “last commit time” and revert
to an older file revision, your
project may not compile as you expect
it to.
Does this warning rightly apply to Visual Studio? Is it safe to overlook this warning or will I run into problems down the road?
Or alternatively, is there another stupidly simple installing scheme that would work in place of robocopy? Keep in mind that I don't want to introduce a lot of extra dependencies, so a 3rd party app, an install script I can't store in SVN, or a solution that requires lot of extra developer training would not be ideal.
One solution would be to copy only files that have actually changed, by checking the file contents. I'm not sure if Robocopy has an option for this, but rsync (for Windows, cwrsync) does.
Edit: oh, sorry, "not ideal". Well, I'll just leave it in case it helps.