Since TFS get-latest operation is non transactional there is no way to abort merging code after issuing get latest. Both Git and ClearCase allows you to backout of rebase operation. So one way I came up with is is to create a shelveset right before I get latest so I can abort and retrieve my code if there's too many conflicts that I don't want to deal with immediately.
My question is is there a way to automate the creation of a shelveset when you do get latest, ideally overwriting an existing one if it exists (say with a hardcoded name "HEAD").
Running the following command will auto shelve current workspace files and get latest:
tf shelve "HEAD" /comment:"Autoshelve" /replace /recursive /noprompt&tf get
You can store it in a .cmd file under your project's root folder in the source control.
Related
I'm coming late to the DVCS party after developing solo for a long time by doing my own version control with copies of folders. For a small project, I would have essentially a folder structure that looked like this:
project
development
release1.0
release1.1 (for a bug fix)
release1.2 (for a bug fix)
release 2.0 (for a new feature)
I'm now getting on board and learning DVCS using Mercurial (SourceTree) and BitBucket, and slowly learning the ropes with both the GUI and command line with some new projects where I could start fresh using DVCS. I'd like to move some of my old projects into DVCS, but I don't want to lose my project history. What is the best path to follow, or is it even worth the effort?
I'm thinking something along the lines of the following (attempting to use an HgFlow methodolgy):
Create repository using code from release 1.0
Commit files into the development branch
Add tag for release1.0
Merge into the master
From the development branch, create feature/hotfix branch for release 1.1
Copy files from release 1.1 into hotfix branch and commit
Merge hotfix branch into develop and master
Add tag for release 1.1
From the development branch, create feature/hotfix branch for release 1.2
Copy files from release 1.2 into hotfix branch and commit
Merge hotfix branch into develop and master
Add tag for release 1.2
etc.
Does this seem like a workable approach? What suggestions do you have?
Yes, your approach is good. The only thing to add it to use hg addremove before you commit the next version of your code. This command can find renamed files for you and will thus help you recreate an even more accurate history.
The workflow then becomes
Create repository
Copy files from release1.0 into the working copy. They will all be seen as unknown (? ... lines in hg status).
Use hg addremove to schedule them all for addition. Adjust the .hgignore file to exclude build output before running hg addremove.
Commit and tag this as 1.0.
Delete all files from your working copy using your normal OS delete command. The files will now be listed as missing (! ... lines in hg status).
Copy files from the release1.1 into the working copy. Files that were changed compared to release1.0 now show up as modified and (importantly) newly added files show up as unknown while removed files still show up as missing.
Run hg addremove to schedule the new files for addition and the missing files for removal. If a file foo.c in 1.0 was renamed to bar.c in 1.1, foo.c will show up as missing and bar.c will show up as unknown. When you run hg addremove, Mercurial will recognize this as a rename. Use the --similarity option to adjust how similar the files need to be for them to be considered a rename.
Commit and tag this as 1.1.
Now repeat for the other releases. The important part is to clean the working copy between each code import — what way you make sure that each commit accurately reflects the state in the folders you used before.
I have a huge repository. A while ago a file with the name FooBar.xml was deleted from some unknown directory in the tfs. What would be the easiest way to find the file? There are thousands of directories in the repository, so manually inspecting each and every one looking for deleted files is not a feasible option.
From a Visual Studio Command Prompt use the command
tf undelete $/TeamProject/FooBar.xml /noget /recursive
This will undelete any files in the repository with the name FooBar.xml, and leave the undeletes as pending changes. If you can narrow it down to a particular branch or area of your repository that will speed things up.
You can then go though the list of pending undeletes, identify the file you want to keep and "undo" the other pending changes.
Is there a way to exclude a specified file from the merge process? when merging from our production branch to the test branch for the testers to use, we want to exclude a config file which contains the SQL connection string. Preventing the need to edit it post merge. I did see a comment about using the cloak option but i can only see this available for folders not files.
Tim
There are a few different ways you can do this. If you don't plan on changing your config file in the future and you just don't want its current contents to make it to the parent branch, you could simply do a "tf merge /discard" on the file and check that in. That basically says, never merge the changes that have happened to this file to the target branch. However, if the file changes again, it will be a candidate for a merge.
So, if you plan on continuing to change the config file in question, then you have two options. The first is to always cloak this file in the target branch workspace that you are performing the merge in. Yes, it is possible to cloak files, it is just the picker in the dialog doesn't make this easy. If you navigate all of the way down to the containing folder, select that and then manually enter the file name at the end of the folder string, the cloak will work on the file. This approach has the downside that you have to remember to always cloak this file in the workspace that you are performing the merge in and if someone forgets to do that, the file will be merged up.
The third, and likely best, solution to this problem is to use the tfpt.exe power tool with the branches command to cloak the config file from the parent's branch mappings. You can download the latest 2010 power tools here. You will want to run "tfpt branches /properties /collection:" and then select the "mappings" channel. In there you will probably just see a single mapping for the root of the branch. You will want to create a cloak mapping for the file you do not want to be merged and then click OK. On all subsequent merges to that branch (note, from any other branch) the file in question will not be merged.
Not a very nice solution, but you could remove the checkin security on that file so you are unable to checkin the file after a merge.
I was recently tasked with creating a branching plan for our project, and part of that involved creating a few feature branches and release branches. I also had to clean up the source control tree so that the branches could be self contained. I basically started with this:
/
./src
./model
./processtemplates
./data
./otherfolders
I changed the structure to this:
/
./trunk
./src
./model
./data
./branches
./v1
./release1
./src
./model
./data
./release2
The problem is, I need to create a branch from a specific previous version, but the folder structure has changed, so I can't get that changeset for the /trunk folder to create a branch from. The exact error message I get is: "No matching items found in $/ at the specified version."
What's the best way to do this? I have though of creating a branch from the latest changeset and reverting all of the changes back to the older changeset. I was hoping there was an easier way.
Renames and deletes are dangerous territory in TFS 2008. You'll probably have to go to the command-line to do this. Take a look at your history to figure out the changeset from which you want to branch, then do the following at the command line:
mkdir c:\BranchFolder
cd c:\BranchFolder
tf.exe workspace /new /s:http://tfs:8080 BranchWorkspace
tf.exe workfold /map:"$/","C:\BranchFolder"
tf.exe branch "$/" "$/branches/v999" /version:Cxxxxxx /noget /noprompt
Validate and check in.
tf.exe workspace /delete BranchWorkspace
replace v999 with whatever folder you want to branch into, and change xxxxxx to the appropriate changeset number.
As always-- when you are working in these kinds of areas where you aren't quite sure what the results are going to be, check your work before checking in.
I'm currently reorganising our TFS source control for a very large set of solutions, and I've done this successfully so far.
I have a problem at the moment where I need to delete a legacy "Release Branch" TFS project that was branched for the old structure, and is no-longer required since I now host a release branch within the new structure.
This is an example of how the source control now looks after moving everything:
$/Source Project
/Trunk
/[Projects]
/Release
/[Projects]
$/Release Branch Project
/[Projects]
/[Other legacy stuff]
So far I've found information that says:
tf delete /lock:checkout /recursive TestMain to delete a branch.
TfsDeleteProject to delete a project
tf delete seems to be only relevant when I need to delete a branch that is within the same project as the trunk, and TfsDeleteProject doesn't seem like it will delete the branch association from the source project (I hope I'm wrong, see below).
Can someone tell me if the above will work, and in what order I should perform them in, to successfully delete the TFS $/Release Branch Project while also deleting the branch association (from right-click $/Source Project -> Properties -> Branches)?
Let me put the facts like this:
Within the context of the TFS source control system, "Delete" is a purely logical operation. You can Undelete at any time. You can have multiple deleted items occupy the same path over time, or even simultaneously. Branch relationships are preserved.
TFS "Destroy" is physical removal. To maintain database integrity, that means all entity relationships are removed too: changeset history, pending change records, shelved versions, merge history, and yes -- branch hierarchy. This Destroy feature was introduced in TFS 2008.
Destroy is the only operation allowed to alter the merge history table (from which branch relationships are determined). All other operations are strictly append-only.
TfsDeleteProject does its best to completely remove all traces of a project, the primary goal being to allow creation of a brand new project with the same name. Some TFS subsystems support physical deletes; some, such as WIT field metadata, only support logical deletes, even in TFS 2008 & beyond. In the case of source control, TfsDeleteProject invokes "delete" in 2005 and "destroy" in 2008+.
In TFS you generally cannot permanently delete anything inside a team project (and TfsDeleteProject deletes a complete team project, but it is not clear if the source control content will actually be removed as a team project is just the top level of the source control tree).
A delete of a file, or whole set of files is just another tracked change, go back into history and it can still be seen.
You could use permissions to make it inaccessible to all. Or rename under an "Obsolete" team project.
EDIT (I finally remembered where this command was):
There is another option, from the command line: tf destroy:
Destroys, or permanently deletes, version-controlled files from Team Foundation version control.
I would expect this to remove the branch records to create the, now destroyed, files... but you might need to check.
Select the branch folder you want to unbranch. then
File > Source Control > Branching and Merging > Convert to Folder.
In VS2013 I couldn't find it under #Radhika answer
I did find it under Team Explorer > Source Control Explorer >right mouse on project > Branching and Merging > Convert to folder
Hope this saves you time.
Edit Copied from comment by #DdW: you need to do a Get Latest Version after converting, before the Delete option will be enabled
REMOVE A BRANCH USING ROLLBACK
Right click on the select branch.
Select rollback to specific changeset.
Enter 1
set.
Choose 1.
The branch will be marked for deletion.
Check in the changes and it will be removed from source control.