I am working with my co-worker on some files, that are in TFS repository. We have to share these files frequently, however, in the process of our development they are neither compilable, nor working properly. We don't want to put them in the repository, because the rest of the crew shall have problems with compiling the solution. However, the manual sharing would be rather painful. Is there a way to put files on TFS, but not inside repository? (mark as temporary, not finished or something like that).
You can use a shelveset - if you shelve your set of changes then your colleague can pick them up and the other members of the team will never see them. It is a bit of a PITA as you need to have 2 shelvesets (1 each as you can only update your own). The only other way is to branch and then merge when you have compilable code.
Another option is to branch the code into a new branch that the two of you use. When you are done working on the file, and it will no longer break the main build, you can then merge that file back down to the development branch.
Related
Another developer has some test files in a new directory in their branch. They're useful to me as well but I'm working in a totally independent, newer branch and he's not likely to merge his branch anytime soon.
I am able to branch his "test-data" directory into my branch but I really want to break the branch association so they're treated as new files in my branch, i.e. so TFS thinks our branches independently added the same new files and we resolve conflicts later since our test data is likely to diverge.
Is there a way to "orphan" the branched files somehow?
You can just get files in TFS using the web access component. Just browse to the folder through the code portion of web access and right click > get as zip.
You can do it from the command line as well but I am not familiar with that. SO has a lot of resources on how to do that from what I have seen.
It is possible to break the branching relationship in TFS and there are many questions on SO on how to do that. But your branch wouldn't initially treat them as 'added' and the history will be in TFS. I would recommend branching just the folder his useful code into your branch and leaving that relationship for posterities sake.
That being said, depending on your situation it may not make sense. If you want to remove the branching relationship immediately, then I don't think you need to use TFS.
Yes this is one of the Doh! Damn! I shot myself in the foot. I don't have a lot of experience with TFS in large teams, but I'm facing this issue.
During a transition to new equipment, a developer forgot to check-in some code. Work proceeded on the new laptop for several weeks before noticing that the previous work was not checked in. Mutliple check-in have occured.
I have recovered the files from the old laptop, and have them on my current laptop. What is the best way to merge in these changes? Do I create a branch, merge in these changes, and then rejoin the branch?
Is there a "cookbook" out there that details what should happen when faced with various situations?
We are using TFS 2010.
Thanks in advance...
Creating a branch here is probably a little bit heavier-weight than what you need for this one-off situation. If it were me, I would do this:
Set up a workspace on your computer with the appropriate mappings.
Do a Get Specific Version to the version that the other computer was at. The best case scenario is if the user never deleted their workspace on the server. Then you can simply specify their workspace as the version and you'll get the files as they existed on the laptop. (You can specify this as Wworkspacename;owner name.) If the user deleted their workspace, you can get based on the changeset number they were at, or based on the date they were working at.
Copy the recovered files on top of the new TFS workspace.
Run tfpt online from the Team Foundation Server Power Tools. This will examine the local filesystem against the server and determine what changes were made. You may wish to examine the options, notably the /diff flags (which performs MD5s on the file instead of simply examining the readonly bit), and the /deletes and /adds flags, which detect deleted and add files, respectively.
Do a Get Latest on your workspace, resolve any conflicts, and check in.
You can follow this sequence to try out:
Make a merge-branch of your code version based on the time-stamp of where your restored laptop code has left the version control system.
Get your branched code to a location on disk.
Perform a check-out for edit of the entire workspace.
Copy the old restored code over the files in this workspace.
Perform a checkin of the local code into the branch.
Merge your latest code (main trunk) into the branch, merging changes, solving conflicts.
If all build and tests out correctly on the merge branch, merge that branch back into the main.
That should do the job.
I started work a lone developer last year and I found VSS is no longer a good option for source control so I decided to use TFS 2010 instead.
I have had to learn everything from a book - of which there are few.
I am currently creating a new build and in my workspaces I see a have 4. I want to delete one of them and rename another.
However I do not know what the consequences of doing this are. If I delete a workspace, will that remove the associated files under source control? How do I check which files these are? What happens if I change a status from active to cloaked?
As you can see, I am a beginner in all this.
Workspaces are only a mapping from SourceSontrol folders onto your local file system. Also workspace contains information about versions of the files you have locally, so when you hit 'Get Latest Version' only recent changes are sent from server to you, not the whole files. Information on what files are checked out is stored in workspace too, so if you have pending changes in the workspace and delete it then there'll be a bit of a challenge to check these changes in. Renaming of the workspace will not break anything as far as I know.
Article An introduction to TFS Workspaces may be interesting to you.
Like the others have said, the workspace only says what local files you have checked out, and the status, etc. Workspaces are pretty granulal (i.e. per user and per machine) so you could have mutliple workspaces with the same username in the same project. E.g. if you have a copy of Visual Studio at work and one at home, you could have different files checked out and you wouldn't run into any conflicts like you would have in VSS or something based on VSS Like like VSSConnect.
We've had a couple of people leave out project and have had to go in and remove their workspaces after the fact. This hasn't been a big deal in terms of any code losses but if you don't have access to the machine anymore you will have to use the TFS tools.
Try TFS Sidekicks, it provides a nice GUI to manage all the nitty-gritty back-end stuff in TFS
We are allowing external consultants to work on a portion of our source. We created a new TFS project and granted them rights to that. Branching does work between TFS projects, so we can branch the "real" TFS project they're working on to the consultant project. However, we only want to expose portions of it. Here's what we want (simplified):
OurProject
Mainline
Applications
Secret1
NewApp
Libraries
Secret2
Shared
ConsultantProject
Mainline-Branch
Applications
NewApp
Libraries
Shared
If we simply branch Mainline and delete the Secret folders on the branch, merging back must be done carefully to avoid deleting the Mainline Secret folders. We want to simplify future merges (both ways) while minimizing risk.
How can this be accomplished?
I know this may not be answering your question, but rather the intent of your question. Why not just set permissions to hide those secret items from the consultants and branch as you would any other time?
I agree with Alex. TFS doesn't have any built-in mechanisms to handle sparse branches. The closest analogue in TFS is branching/merging by label, but that strategy brings a ton of management overhead which is very error prone.
So, just let the branch/merge system do its thing and use ACLs to ensure your consultants can't see the Secret Sauce.
Note that for complete security, you'll need to create a 2nd solution for them that does not include any of the Secret projects, then ACL the main (all inclusive) solution out of sight. Do any non-Secret projects depend on the Secret projects? If so you'll have to do something similar (though slightly more involved).
Instead of branching and then deleting files/folders from the branch, branch only the files that you want them to have access to.
eg:
Branch Mainline -> $/ConsultantProject/Mainline-Branch.
Right click on $/ConsultantProject/Mainline-Branch/Applications/Secret1 and undo your checkout.
Similarly undo checkout on $/ConsultantProject/Mainline-Branch/Libraries/Secret2.
Check in your branch ($/ConsultantProject/).
With this completed, merges from one to the other will not affect the files/folders that you didn't branch.
TFS really likes for all dependencies of a project to be inside one folder. I would restructure your folder layout quite a bit. Here's how I would do it.
TeamProject
SecretApplication
SharedLibrary1
Application1
SharedLibrary1
SharedLibrary1
ConsultantApplication1
SharedLibrary1
Here's the detail...
Notice how all the apps are peers? SharedLibraries are shared/branched into the apps that use them. That way apps can move forward at their own pace and pull down shared changes at their own pace, and merge their changes to shared code back at their own pace. TeamProject->SharedLibrary1 is the "mainline" for SharedLibrary1. Everywhere else you see SharedLibrary1, it's a branch. Each application folder is its own "mainline", making your structure more app-centric than "all our work" centric.
With this setup, you merely make a branch of Application1 and call it ConsultantApplication1. That way you can setup your security to allow your consultants to only see that one app and all its dependencies. They can merge and pull at will. Well, they won't be able to merge without seeing the source project, but you can. All other apps in your team project will be invisible to them.
Let me know if I've misunderstood something or there are some requirements preventing you from using a structure like this. If there's a secret shared library under Application1, we'll have to think on this some more, but I think that would have compilation issues anyway. Regardless, placing all dependencies for an app under a single folder helps a ton and is a great practice.
This question is a derivative of a previous question: How to version resources that are shared across projects
I have a project that contains code that is consumed by many other projects. Specifically, one folder in this parent project has been branched to dependent child projects.
We have since made changes in the parent project and checked them in. In Source Control Explorer, I right click on the branched folder in the parent project and select "Merge", intending to push the changes to a dependent project. I select the child project as a destination and then select "Latest Version". The wizard informs me "There are no changes to merge."
From my perspective, this isn't true, since the recently updated files are clearly different.
Is there a fundamental misunderstanding of the merge process in TFS here? What do I need to do differently?
The TFS merge engine relies almost entirely on history, not file contents. This makes it efficient for very large trees, and flexible for tasks like safely cherry-picking changes -- but it also makes answering your question difficult.
The first step is to understand the diagnostic commands tf history, tf merges, and tf merge /candidate. Here is a good introduction: http://blogs.msdn.com/dstfs/archive/2009/04/15/a-note-on-merging-and-the-use-of-tf-merges-tf-merge.aspx
If you are new to branching & merging in TFS then your history is probably not very complex. I think it's likely you'll find your answer with one quick call to tf merges. However, tracing merge history can become extremely convoluted in the general case, so if you have trouble feel free to post back with more details.
Go to one specific file you know has changed in your "parent" project. Try merging just that file. Don't check anything in; just see what happens.
Something to watch for: The merge tools will not include files that have been added after you branch. You have to branch new files explicitly before you can merge any further changes. If a file is added to both parent and child folders without using a branch operation, the merge tools don't treat them as versions of the same file (and you can't merge changes between them).