We have e.g. an excel sheet in the repository that is used for code generation. When any developer has checked out the excel sheet it should not be checked out by anyone else. This can be done by specifying the "Check Out lock type" via the check out dialog. But this has to be done manually by the developer. Is there a way to force this lock type on several files so that it is used automatically?
You can specify which file types are mergeable. You can change the setting in Team -> Team Project Collection Settings -> Source Control File Types.
Related
I am using Visual Studio 2107.
Looking at the “Pending Changes” panel in Team Explorer, there are two list for “Included Changes” and “Excluded Changes”.
I can use the Filters option to display only files that match a certain pattern. However, I want to be able to hide files that match a certain pattern.
The reason is that I have a number of files regenerated during the development process; these files all have the same name in different projects. They clutter up the list when I am reviewing what to check-in.
Note that I don’t want to exclude these files from being checked-in; they will be checked-in to source control eventually. I just want to be able to review the Changes list without these files displayed until I want to see them.
It seems straightforward but I can’t seem to figure out how to do it. And I can’t seem to find the right phrasing for Google.
How do I hide files in Team Explorer Pending Changes View?
If you don’t want to exclude these files from being checked-in, I am afraid you could not hide files in Team Explorer Pending Changes View.
According to the document Develop code and manage pending changes:
Almost every change that you make to the files on your dev machine is
stored in your workspace as a pending change until you check it in.
If items that you don't need to check in appear regularly in the
Promote Candidate Changes dialog box, you can select one of them, open
its context menu, and choose Ignore this local item to ignore the
item. You can also choose Ignore by extension or Ignore by file name
to create a file that will cause Visual Studio to systematically
ignore this kind of file.
So, Pending changes will detect all your changed files unless you don't want to check them in.
So, to hide files in Team Explorer Pending Changes View, we need to use .tfignore file to ignored files to folders that are mapped in a local workspace, they do not appear in the Pending Changes page in Team Explorer. When you want to check them into source control, you can move them out from .tfignore file.
Hope this helps.
Hiding files from Pending Changes is not supported without fully ignoring them.
I'm doing some tests with TFS prior to moving all of our source there.
Right now, I've created a very simple solution and I've set two workspaces, one local and one in the server.
With both workspaces on the last version, I've made some changes in the server workspace and checked them in. Then, I've made some other changes in the local workspace and I've tried to check them in too. Of course, there is a conflict, but I only get the option to keep the local changes or take the version from the server. I would expect to see an option to merge the different changes.
I'm pretty sure I've seen the option to merge before, in some other tests I did some time ago...
Any solutions? Am I doing something wrong?
UPDATE:
I've clicked in the "Annotate" button and it tells me it can't be done because the file TestApp.cpp is a binary file (Error TF206000). Maybe I should add that I've moved the files from git via git-tf. However, the file on my computer seems fine, ANSI-coded, with CRLF line endings, and no strange looking characters in notepad++, or any other editor I've opened it in...
UPDATE 2:
Answering MartW's comment: The file on the server looks the same as on my PC. Well, there seems to be some encoding issue, since the accents are not shown properly. Also, it doesn't let me annotate the file on the server through the browser, with this error: "Valid values are between 0 and 65535, inclusive. Parameter name: codepage".
I've checked through the versions, and I can annotate the first one where the file appears. All the rest give the same error.
Whether merging or not is available for a particular file type is dependant on the file extension, and controllable via the TFS Source Collection settings.
In TFS 2013, this can be accessed from within Visual Studio and selecting Team => Team Project Collection Settings => Source Control. You'll see a list of various file types and associated extensions, along with whether file merging is enabled for those types. CPP files are under the C++ section and should say Enabled - perhaps this is Disabled in your setup?
OK, I think I found it. Apparently, TFS has decided that all my files are binary files. By going to the Source Code Explorer, selecting the file, opening the context menu and selecting Advanced|Properties, I've been able to change the encoding (actually, if I tell it to auto-detect it, it does it just fine) and now I can merge...
Now, I have to find how to change the encoding of all the files (well, just text files) at once.
I have two VS2013 sessions opened, each with a solution that is version controlled by the same visualstudio.com TFS repository.
In one project I wanted to check in some files, but Check In will always want to check in changed files from all my other VS projects.
Is there a way to make Check In work only on the current project?
It's very confusing when checking in project A also checks in project B when I am not ready or certain about the state of project B.
Check ins are based on your workspace, not the solution or project you are working on, which means a check in will always detect changes made in any of the folders that have been mapped from source control, regardless of which instance of Visual Studio they were made in (since it looks at the physical disk to determine what changed).
You can be more specific about your workspace mappings and/or use multiple workspaces if you wish to have a smaller scope for your check ins, though this brings with it usability complexity as you now need to ensure source control explorer and pending changes are referring to the correct workspace.
If instead of checking in with no scope (defaults to workspace wide) you can right click on the scope you want.
If you right click on the solution and select check in, Visual Studio will filter the checkin for you. It will be scoped to only files in that solution.
Whenever this happens to me, if I have made changes in the VS instance i do not want to check in, then navigate back to the one i want to check in, I am presented with an alert box that says something like "the files have changed, would you like to update them?" If this is true for you, you could just say no.
Alternatively, if the each VS instance is touching code in different branches, then you may choose to "exclude" (in team explorer) these other-branchly files.
i'm working with TFS and i need to edit file localy without checking it out .
another case if some one checked in the file and i need to change my locally copy.
what should I do ?
in Visual source safe we can do that by removing the read only check on the file.
Ok, this is relatively easy in VS2010, and quite normal. I mean the locking model of source control is obsolete anyway.
In vs2010, click Tools -> Options -> Source Control -> Environment and select Allow checked-in items to be edited. This should stop the TF client from marking files as read-only.
Also you may have to change the Editing drop-down in Source Control -> Environment to Do nothing.
Well.. You can certainly unmark the file as read only and edit it in something other than visual studio. Or, you can still use visual studio, but not edit it when the solution it's a part of is opened..
Quite frankly, I'd look into other options with regards to why
1. that file needs to be in source control.
2. If it does need to be in source control, why does your copy need to be different.
Just unset the read-only flag on the file locally.
You may have some issues later when try to do a "Get Latest" operation, which will warn you about a locally writeable file.
The title pretty much says it all.
I'm using a RFT, VS addin that allows me to edit a proprietary data file with a GUI. The problem is that this file doesn't show up in VS and when I start editing it via the GUI, VS doesn't check it out automatically (probably a bug of the VS addin). So, I've to check it out manually before editing it, otherwise the addin will crash when trying to save the file (because it is read-only), and sometimes will also corrupt the local working copy of this project.
Everything would be much easier if TFS didn't mark the file not checked out as read only.
Do you know if there is a way to instruct TFS to keep all the files as not read-only?
No. You can exclude it from source control, but that's probably not want you want.
I have the same issues with TFS. Our project has a few small SQL Server database files that we have chosen to put under source control. We handle the read only issue by adding these to the post build statement on the project build. I suppose we could have done this pre-build as well.
attrib $(TargetDir)*.mdf -r
attrib $(TargetDir)*.ldf -r
It has been a while, but - I think this link is actually the answer to that.
When you do a check out, what you are actually doing is saying “TFS, I
would like to edit the version of the file that I have already
downloaded, is that ok?” TFS then looks at that version, and tells you
if you can edit it or not (based on your security permissions at that
point in time and if anyone else has placed a lock on the file). If
you can edit the file, the TFS marks the file as read/write on your
local machine and allows you to proceed.
I.E: When I r.clicked the project and selected "Check out and edit", the r/o flag was automatically removed, and I could compile (with both pre/post events) and then "check in" again.
Well you can get latest to a samba share, which eats the readonly bit.