I have an application that is developed without any version control system so far, and I want to use TFS version control from now.
I have different copies (snapshots) of projects files stored at different times of project development and I want to store them in TFS repository too.
Can I use single workspace and copy each version to that workspace
and check in? Does the changes to all files captured automatically this way?
Where can I submit time and version history for each stored version?
So, you have the project in its current state and versions of it from previous dates?
From my experience, it's best to check-in the current version in Tfs as you would do for a new project. This becomes your working copy and all future changes are checked-in/checked-out and tracked in history.
For the pervious version, create an Archive folder in TFS with sub-folders for each date when you kept a copy of the project. Check in all files of that version into the appropriate folder. This can be used for reference.
Related
A while ago, I moved a large number of files into an new project to better organize my program. Now I have discovered that all history have disappeared since TFS (of course) solve it by removing the files from the old location and create new files in the new location.
My question is whether it is at all possible to restore the history for the files?
This can only be accomplished by using a migration tool like OpsHub or the TFS Migration Tools.
You will have to destroy the files in their current location, do the migration and then re-do the changes made since the migration. There is no way to check in the history "behind" already checked in files.
How badly do you need the history? And Could you live with the history being in the old project?
Is there a way to tell TFS that one or more files has been moved/renamed by another application (in our case, WebMethods 9) running in Eclipse? We have to move/rename the files using WebMethods and not TFS, because WebMethods does a whole lot of automatic reference updating. However, we haven't found a way to tell TFS "hey, trust me - I moved/renamed/deleted it outside of TFS". Instead, it refuses to commit any changes back to the repository until the old file reappears.
We're working around this at the moment by creating dummy files with the old name and then deleting them again via TFS, but you have to agree that kinda sucks. I'd be happy to treat a move/rename as a deletion of the old filename and creation of the new filename; I just don't want to have to fight TFS over it.
Eclipse: 3.6.1.M20100909-0800
TFS plugin: 11.0.0.201306181529
It depends on whether you use server workspaces or local workspaces.
In a server workspace, TFS requires that you inform the server for every change - to check out a file, rename, delete, etc. This allows TFS to avoid scanning your disk for changes, which is beneficial for large repositories. If you want to force a disk scan with Team Explorer Everywhere, because you may have made some changes outside of Eclipse, you can go to the Actions menu and select Detect Local Changes.
In a local workspace, TFS will examine your disk for changes every time you look at the pending change status. So all you have to do is run tf status or click refresh in the Pending Changes View to see changes made to files outside of Eclipse.
If your workflow involves files changed outside your IDE frequently, I would strongly recommend using local workspaces, however this requires TEE 11.0 and TFS 2012 or better.
Maybe I have hallucinations, but I'm pretty sure of what I'm saying (I am new to GIT): I have some java code on my local drive, never versioned (to any versioning system, neither GIT nor SVN or whatever). I've created a repository on bitbucket, then I imported the source code from local drive. I did some testing, following a tutorial. Everything worked fine since I've noticed that, in the history folder (I am using the Eclipse plugin) I could diff two older versions of a file (and have the correct diff displayed), but these changes were made BEFORE I even created the git repository (local and remote).
I cancompare two versions saved yesterday:
I![YESTERDAY][1]
I can compare two more recent versions (today):
![TODAY][2]
-- I cannot post images, not enough reputation :( --
Notice that I installed GIT (and created the bitbucket repository) TODAY!
It's Eclipse tracking the history. I have a toy Java project open in Eclipse—which has not been commited to any source control—and I am able to diff against previous versions I saved yesterday.
To see for yourself:
Create a new Java project
Create a new class file
Make several changes, saving each time
Compare with > Local history...
I have got 8 projects.
Projects referencing each other.
I exclude all dll files of my own projects from sourcecontrol
But every build the dlls gets changed and tfs enters into the conflict mode.
I want to avoid it.
is that possible ? And how ?
Thanks
PS: Tomorrow is my birthday this would be a great present
Delete those DLL's from TFS source control. Probably they are checked in once and now TFS will try to update them constantly when they change.
We have a new ASP.NET project on VS 2008 environment, and a new TFS server was setup for it, but originally the bin folder of the project also got checked-in.
The team has about 10 active developers at a time and it a big issue now as some of the common libraries remains checked-out by someone or other.
As per the best practice, I now wish to fix this issue and remove the bin folder out of the version control AND I need to ensure that from now on, when a developer checks-in his project, the bin folder again does not gets checked-in. How do I ensure the both things with the correct approach? It would be great if I can do something as an TFS Admin so that from the next day all developers automatically get some settings pulled into their boxes so that they stop checking-in the bin folder once I have removed it from TFS control.
I am a beginner in TFS, as earlier I used SVN primarily, so please point me to the proper steps, documentation. Thanks!
Delete the bin folder in solution explorer, this will add a delete to the pending checkins.
A build should re-create the bin folder, but not add the folder to the project (and thus there'll be no prompting for it to be added to version control).
This won't prevent someone adding it (or anything it contains) back into version control outside of VS (eg. from the command line, or adding the bin folder back into a project). I don't think there is anything you can do to stop arbitrary files being added except training (if your developers cannot handle this, how do they handle all the other "don't do that"s associated with development?)
Updated, since this was written TFS (including VSTS and Visual Studio1) allow files and folders to be ignored via a .tfignore file.
1 Often Visual Studio does not pick up changes to the .tfignore file, needing a restart.