At work we are using TFS Team Foundation Version Control (TFVC) and the workspace is a server workspace (very large codebase). The limitations of our setup are that files checked out are locked for edit by other people. Also there is a culture of not committing until work is complete etc as many change-sets complicate merging later.
I am in no position to change the global rules or culture. I would like to locally setup a mercurial (hg) repo on my local machine. The idea is that I can work on my local copy make as many checkins to hg. When I am done I would like to bundle my changes into one changeset and send it off to the TFS location (also on my local machine). Then immediately checkin the changes to TFS server.
That way to the outside world I appear to checkout and then immediately checkin all of my code, only briefly locking the files changed. But locally in hg I get the full ability to make small checkins and work without worrying about locking files out for edit.
Somehow chain two version control systems, giving me the flexibility of HG locally, but continue using the global TFVC for final checkins.
Any ideas on how this could be achieved?
You can use git-tf and the hg-git. This was an intentional design decision when we built git-tf that this was a supported scenario.
That said... this seems a bit... icky.
You may want to write a few shell scripts to make this workflow a little bit easier.
But even with that, it's hard to imagine troubleshooting this when something inevitably goes wrong.
TFS doesn't have Mercurial support, but apparently does have Git support.
You can use the hg-git plugin to access TFS this way.
More details about the lack of support:
https://hglabhq.com/blog/2014/1/17/mercurial-support-in-tfs-declined
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3607357-add-mercurial-support-to-team-foundation-server
Related
We have been hired by a client who would like us to check in code to their Azure Devops Team Foundation Version Control server.
We have our own small team of developers that will work on this project and commit changes to our own TFVC server first. Once all check-ins are approved, we would then like to commit all of our changes to our client's TFVC server. We have been given a single login to their TFS system, so we would like to check in our code into their system using the single login that was provided to us. The client does not need to know the history of all of our own developer's work, we would like them to see our check in as a single author. We don't want to migrate, as this will be a common task for us.
What's the most straightforward way we could do this?
It is not possible to sync code on 2 different TFS server. Since you work in one workspace (command line and GUI) at a time. And a workspace cannot span servers.
The only workaround here is manually copy/past your code directly through windows file system. Finally check in code to your client's TFVC server.
The better solution is to convince your clients to use Git repositories instead of TFVC. There is a lot to win here! And you could migrate your sources with git-tfs with all history.
We just started test-running VSO for source control/Scrum management on a new project. We currently use TFS running in-house for other projects. I love the VSO scrum tools, but, with today's VSO outage, we are questioning whether VSO is practical for us as a source control.
After researching this afternoon, I don't see a solution to have a local backup of VSO. My current thought is to use a local git repo that pushes to VSO. The problem with that is switching technologies is not an easy sell, especially when we already have the local TFS to maintain.
We have thought of using VSO to manage scrum tasks and keep source control in-house, but I really don't like having the two separated (can't link commits and I think that everything should be in one place if possible).
Yes, for you purists out there, we do have a big whiteboard with index cards and stickies for our sprint tasks, but we're still looking at the cloud as another option ;)
To condense my rambling into a real question: Is there a way to use in-house TFS as a local repo that pushes to VSO, or to at least have it mirror VSO?
Are you concerned with VSO losing your source (extremely unlikely), or just experiencing the occasional outage and not being able to check in or get latest for a time?
Using git for source control would be the simplest approach, as you've stated. You'll have the full repository on your development machine and can make whatever commits you like. Changing source control would mean upskilling the team on git, creating a new team project and using git-tfs or git-tf to migrate the history, so I understand why you might not want to change.
With TFVC, if you are using a local workspace you should still be able to work during an outage and make changes. You just won't be able to check in. If VSO has an outage it'll be an inconvenience but shouldn't stop you working.
In terms of using TFS as a mirror that pushes automatically to VSO, the simple answer is "No, you can't do that".
If you used git, you could set you local repository to have two remotes, one being the local TFS server and the other being VSO, but it would still be up to you to push/pull the changes manually between both servers yourself to keep them aligned.
I'm building a tool to integrate with TFS and it needs to properly parse TFS logs (from the tf.exe history command) and checkout different revisions (again using tf.exe). It works great on the test TFS server I have, but I want to test it on a broad range of large repositories to make sure my parsing works properly.
I'd hoped to use Codeplex to get access to TFS repositories, but it seems you only get TFS access to Codeplex projects if you're a project member.
Are there any collections of open source code hosted on public TFS servers? Are there any other publicly available servers I could use for testing?
I would suggest using svn2tfs and choose any relatively active project on SourceForge. There are plenty of projects on SF to choose from that use SVN and not CVS. You might even get a bonus out of it and help the svn2tfs project work out any kinks.
Since you mention tf history command, I assume you want to collect/parse logs on the project's (and its files) history of checkins.
So in addition to large repository, you also need a good amount of history, am I right? If yes, then here's your set of problems:
Most projects on codeplex use Mercurial, not TFS. So even if you get access, you cannot use TFS with them.
As you mentioned, they require you to a be a member for you to access the source.
Even if you get access or find a public server (unlikely), you still would need good amount of history.
If I'm correct in my assumptions so far, here's the easiest (bit tedious though) way out:
Go to any large projects's such as Nuget or Wix
revisions
Download any old revision (go back as far as you want the history for). You can download zipped src files without being a member.
In your test server, checkin the code (src) to create the baseline.
Download the next revision.
Checkout files in your server and overwrite them with the newer revision's files.
While checkin, use the history.txt (sample) to create checkin comments
Repeat this process few times.
Voila!! You now have a large repository with lot of history!
Hope this helps.
Have you tried some of the larger projects on Codeplex?
http://www.codeplex.com
If you only need read access you should be able to play around with the various repositories.
I don't have a huge amount of tfs experience, but I would assume there are migration tools that let you ingest code repositories from other products (e.g svn or hit).
If so, you might want to find a svn/git repo for a sizable foss project, and try importing that.
"I'd hoped to use Codeplex to get access to TFS repositories, but it seems you only get TFS access to Codeplex projects if you're a project member."
This solution appears to be the general consensus amoung SO'rs. I've read some of the Codeplex TFS connection problem threads (you linked to below) and I hope the comments in this thread resolves the issue:
Connecting to Codeplex TFS as a Coordinator or Developer.
I'm wondering if you can use git-tfs project to import an existing Git project into TFS.
Download and install git-tfs
Create a new TFS project
Clone the TFS project to a Git project using git-tfs ("git tfs clone http://tfs:8080/tfs/DefaultCollection $/some_project")
Import a existing Git project of your choice into your fresh new Git project (I don't know the command but I think it's possible).
Use git-tfs to checkin to TFS Server ("git tfs checkintool")
=> Do it makes sense ? And works ?
For more information:
http://lostechies.com/jimmybogard/2011/09/20/git-workflows-with-git-tfs/
Let's say I have my TFS team project setup the way I want it, and all the code between my machine and the team project is in sync (i.e. if I do a get latest it says everything is up to date).
What I would like to do is test whether or not I can pull the project back down to my local machine from TFS source control have everything work properly. By work properly, I mean I'm able to build all the projects, run the web sites, etc.
I thought what I could do is just blow away the code on my local machine and then do a get latest. But TFS seems to think that my local machine and TFS are still in sync (this is a bit different from the way Visual Source Safe worked).
In a nutshell, I'm just trying to test whether or not if another developer were to pull this team project down to their machine, that I know the project is setup correctly with all the necessary dependencies, etc. such that the other developer could build and run the project. But since I only have one machine to test this with currently, I need to do this test on the same machine.
The only way I've found to do it is to use "Get specific version" and force it to overwrite existing files, but it seems like if I delete the stuff off my hard drive, it should know when I do a get latest that "hey, the files aren't there anymore, I need to pull them down".
Any ideas on how I can do this? Thanks.
Not withstanding the answer above highlighting the merits of having an automated build process and continuous integration...
The easiest way to validate what you've checked-in is to create a new workspace with the same folder mappings, albeit to a different location on your hard-drive. You can then 'Get Latest' into this new workspace and confirm that everything builds locally, this should prove that:
The correct versions of existing files are in source control
All the required files have actually been added to source control
Alternatively if you'd rather not check-in your changes until you've validated your pending changes, then your best bet is to 'Shelve' all your changes (ticking the box to undo your pending changes), and then 'Unshelve' that shelveset into a new Workspace and do your testing against that instance of the codebase... or even ask a colleague to pull down your shelveset and do the validation (typically this called a 'Buddy Build').
TFS is a little different that VSS in that local workspaces are maintained so that every file doesn't have to be compared with every GET. In addition to removing the code from your development machine, you should also delete your local workspace. Check out "Working with Version Control Workspaces" on MSDN:
http://msdn.microsoft.com/en-us/library/ms181383.aspx
Really, though, the best way to make sure that your code can be pulled down and built easily is to create an automated build in TFS for continuous integration. That way you know immediately if you have done something that would make the solution un-buildable.
Check out the overviews of Team Foundation Build on MSDN:
http://msdn.microsoft.com/en-us/library/ms181710.aspx
The answers above are good. Except it will not completely test you entire scenario. If you have references outside of your solution (such as dll in the GAC, or dll from an SDK installed on your machine), creating a new workspace or deleting and getting latest code won't found those problems.
The only way to make sure is to pull down the code on another computer. If you don't have another computer handy, you can use a Virtual machine.
Do Get Specific Version and specify the latest. This will force TFS to download everything, ignoring the current synchronisation status.
TFS uses your workspace to know what is synched between the server and local.
I don't think there is an option to make Get Latest to behave like you want (Get Specific Version and specifying Latest Version and Overwrite).
I'm a consultant whose client runs a TFS 2005 repository. I manage my own source code in TFS and deliver my releases to their TFS. My source code is around 20,000 files that I maintain.
My normal process:
Detach my solution from my TFS
Connect to their TFS
Checkout the entire project
Overwrite my project files with
theirs
Check everything back in
Click the add button and add any new
files that have been added
Check everything in
Open the solution file and bind it
to TFS
Check everything back in
The main problem I'm seeing with this approach is if I delete a file on my end, I don't have a way to reflect that change.
I'm also not interested in synchronizing tools because I don't want to synch every checkin, just the current state.
Is there a way I can do this better?
What about maintaining parallel .sln and .proj files with the different bindings? Do they change often?
I think you can maintain change history by using the TFPT ONLINE command from the Team Foundation Power Tools.
Open SLN_A
Make changes (VS auto-checks out against TFS_A)
Before checkin on TFS_A, run TFPT ONLINE against TFS_B. This should pick up adds, edits, deletes.
Checkin SLN_A on TFS_A.
Checkin SLN_B on TFS_B.
Only problem with this might be that the SLN_A checkin could screw up the SLN_B pending changes b/c the files will be returned to read-only. Not sure.
Why do you need to maintain a parallel TFS? Seems like you ought to be working directly against their TFS, either on a branch, via the Proxy, or both.
Have you looked at TimelyMigration? (No affiliation and I've never had need to use it)
TFS to TFS migration