I am using Visual Source safe 2005, I am having problems with some files (.cs and .cshtml)
when I am trying to check in them its giving me this error
the file cannot be checked in because it has different encoding and checked out multiple times
I am not using any encoding, these are normal Csharp and Razor view files.
I read on internet to install updates of VSS, I did this but still same problem.
This problem arising few days back,before that they were checkingin normally.
I am using windows 7 and VS 2010
VSS2003 didn't recognized the [project].vspscc files as Utf-8, and treated them as Ansi; VS2010 recognized them as Utf-8, and doesn't allow you to checkin new versions when the file is multiple checked out. This is by design.
What you can do is undo checkout of the file in the VSS database and leave the file checked out only once. Then use VS to checkin the changes to your solution. If there aren't changes to this file, VSS2005 will not change automatically the file type in teh VSS database. You can open the file's Properties dialog and manually change the type "Ansi/Mbcs" into "Unicode (Utf-8)".
Related
I am working on a project which is on Visual Source Safe(VSS). Me and my colleague were working on the same file. I am working in Visual Studio 2010 with VSS 2005, while my colleague was working in VIsual studio 2013 with VSS 2006.
My colleague committed her changes with no errors, but when I tried to get latest version of the file I am getting this error:
Cannot be merged because visual source safe doesn't support merging of
files with different encoding
The option that worked earlier for such an error is completely deleteing a file from local drive (of course keeping a backup copy!), and then recreating the file from visual studio & copy pasting the content from backup file.
But I am sure there will be some way out as the method I followed earlier doesn't seem to be the best practice.
Also, I cannot check in file; same error arises.
Any help would be appreciated.
Please check your file encoding in Visual Studio and the version in VSS database and see if they are the same.
To check the encoding in VSS, please locate the file in VSS, right click it -> Properties and check Type field.
I am working with a project (shared by a small team via SourceSafe source control) with four .config files in it:
App.config is the configuration file that is eventually used when the program is executed.
The other three files are essentially templates that I can quickly copy & paste into App.config.
App.Integration.config and App.Release.config are valid for all team members. For instance, it refers to integration or production database servers on the network.
App.Debug.config is a template with settings that are valid only for my machine, e.g. because it refers to my local copy of a development database.
Background: Why am I managing multiple configuration files manually? ASP.NET web projects automatically support multiple configuration files, but other project types don't. I also know that this could be automated by adding a custom MSBuild task to the project file; however, this might break or confuse later build steps, such as ClickOnce deployment.
Obviously, I do not want to check in "my" local version of App.Debug.config into SourceSafe, which is why I told Source Safe to ignore that file. For the same reason, I have SourceSafe ignore App.config, because that file is often going to be edited, e.g. when switching from the local configuration file to the integration environment's version. If everyone checked in their versions of these files, they would be seen by all other developers.
However, if I understand correctly, this leads to SourceSafe no longer keeping a copy of these files at all, so if someone checks out a fresh copy of the project, these two files will be missing.
Is there a way to have an "initial" copy of e.g. App.config in my SourceSafe repository, but at the same time prevent Visual Studio from checking out the file when it is locally edited by a developer?
Background: Why am I using SourceSafe at all? It's not my decision, and I can do nothing about it in the short term.
You can use the pin feature to keep a copy but not allow checkout.
In solution explorer, locate your file (e.g. App.config), right click on it to call menu "Show History...", select a version of your file and then click button "Pin".
My current project is under source control by clearcase. I am also using Resharper 8.1 with Visual Studio 2012. I am also using a VS integration for ClearCase.
When adding files manually to a project (by right clicking on the Project -> Add-> Class), ClearCase checks out the project file, so that saving all files works like a charm.
"Unfortunatelly", I tend to use a lot of the ReSharper functionallity. When using ReSharpers Move To command, it seems that ClearCase prevents ReSharper (or Visual Studio) to check out the project files. They are modified, but cannot be saved - I always get that Save As dialogue when saving all documents. To get this working, i need to manually check out the *.proj file and then save the modified files. Is there a way to automatically check out those files?
Another problem is when using ReSharpers Rename: I just tried to use Rename on an interface that is used in approx. 60 other files. Everythink worked, except that the files were not checked out by clearcase! In order to save, I needed to Save all, click cancel for the first file (ClearCase then recognizes that the file has been modified and checks it out) and then save again. This is really annoying and prevents from a produtive workflow..
I'm working with Visual Studio 2010 Professional and use git with Git Extensions as a version control system. When I checkout a branch that involves different versions of the files which I'm working on, VS2010 prompt me with a message that says: "this file has been modified outside of the source editor. Do you want to reload it?" I click yes to all, and get the right version of the files. Until here everything goes as expected.
The problem comes when I checkout a branch that involves files to be deleted. Files that in that branch do not exist yet/anymore. If one of these is opened in the editor, it continues there and you can keep writing on it and then save it.
I know the files can't disappear from the project tree, because we're not keeping track of the project files (at least they get in Project File explorer an exclamation mark telling you that the file doesn't exist anymore). What I want is Visual Studio to close each file that no longer exist. Is there a way to do that? Or does someone have an idea to achive this workflow?
Closing and opening Visual Studio again does the trick, actually does exactly what I want.. But it would be good to avoid it.
Thank you
I think you have forgotten to include the project file vbproj or csproj in git
I'm trying to use Visual Studio 2005 with ClearCase eclipsed files (view private which "eclipse" a versioned file), but any time I save the file in VS, it becomes uneclipsed, and returns to the versioned file. In Linux, I use VIM instead of Visual Studio, and get around this problem by setting backupcopy=yes, thereby forcing it to save files by writing to a new file and then copying the new file over the existing one, instead of moving the original file out of the way (which undoes the eclipse) and then writing a new file, but in Windows, I'd like to use Visual Studio (since the tree also includes C# code compiled under VS). Is there any way to teach it to save files this way?
I do not think Visual Studio does save file in a particular way that may cause the file to be first removed, then written.
Considering that, with developer's environment as Windows with Visual Studio, eclipsed
files often happen just by writing a file case sensitive and later not case sensitive.
Hence, did you check the case of your file ?
Could you also check the config spec associated with your Windows view ? (and compare it to your Linux view).
I just spend 1/2h with a Visual Studio 2005 / ClearCase / dynamic view and... I do see the same thing!
The only workaround I can fathom is to add a non-selection rule:
element /my/private/file -none
That way, even though VS2005 remove then add the private file when saving it, ClearCase does not try to restore the versionned file, since it is not selected at all.
Si, the answer may not reside within VS2005 (I studied the options without seeing any obvious setting altering the saving process...), but rather within ClearCase.
Let me know if it helps.
As noted in the comment, the downside of this approach is "un-eclipse" can no longer be a matter of moving/removing the private file to let ClearCase dynamically restore the versionned file.
Now, that step must be complemented with another one, which is to comment the non-selection rule in the config spec.
If anyone is still reading this... I just discovered that Visual Studio 2008 appears to work just fine. Go figure...