I am looking for an alternative to branching in TFS with the goal of allowing multiple developers to continually integrate into a single changeset that is not in branch (aka a shelveset).
I know that a single user can update their own shelveset, and other users can pull that shelveset - but is it possible to allow several users to modify the same shelveset?
I understand that branching is preferred but I would still like to know if it is possible, maybe by using some sort of TFS powertool or modification.
No this is not possible. A shelveset is owned by a single user. it's also not recommended, as the shelveset is only a single snapshot of the change.
If you'd like something like this, you could consider git tf to create a local git repository which can be synced between two developers. Once they're finished one of the developers can push the change(s) back into TFS.
Moving from TFVC to Git has become easier with the release of TFS 2015u1:
Team Services | TFS 2015
In Team Foundation Server 2015 Update 1, a project administrator can add a Git repo to a team project created with Team Foundation Version Control (TFVC). You can also add a TFVC repo to a team project created with Git. This allows you to adopt a new version control system while preserving all the data in your team project.
As to ways to persuade people to move, that's a hard question. You'd first need to understand what is holding them back, explain the, what advantages Git brings, what disadvantages you see in the current setup. You will probably need to hand-hold or train them so they get comfortable with Git. Using git-tf for a while may give them more confidence to make the move.
Related
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
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.
At my work, we have a number of separate TFS projects that are combined together to form our Visual Studio solutions. These separate TFS projects are maintained so that we can reuse code across multiple solutions. Admittedly, this was a bad idea, as now when we have to branch we must branch each TFS project individually (we even wrote an app to do this). We end up with a project structure that looks like this:
$/Production/[superproject]/MAIN
$/Production/[superproject]/dev/[branch]
$/Production/[dependency1]/MAIN
$/Production/[dependency1]/dev/[branch/
where [superproject] requires [dependency1] within the solution. We end up mapping all these projects to the same workspace.
I would like to use Git-TFS in order to use Git in my day-to-day development. So far, the best way I have found to do this is to have a "master" git repo with a submodule for each TFS project. This way I can branch, diff, etc by using git submodule foreach.
Unfortunately, our policy regarding checkins is to have one changeset for a task, even if the changeset spans multiple TFS projects. This is fine if all my changes are constrained to one TFS project (i.e. one git submodule), but when I have changes across multiple submodules for one task then I don't know what to do. My current plan is to shelve each individualy using git submodule foreach 'git-tfs shelve mytask_$name' and then pull each into my TFS workspace, checking in from there. That only works for whatever TFS branches I have already mapped, which defeats half the purpose of using Git in the first place.
Has anyone encountered a similar problem? Are there any solutions already out there, perhaps using the TFS command line & a script? If not, I suppose I will spend some time creating a pull request for git-tfs. I am open to using Git-TF if the problem is solved there.
Thank you all in advance.
I think there is an effort in this way here : https://github.com/git-tfs/git-tfs/pull/350
you could have a look and contribute ;)
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 a person is working in a small team SCRUM environment. Several teams are working on different branches of the same code base. In our team we usually split up into pairs to work on code. Occasionally people need to take time off etc. and it would be advantageous to be able to merge person A's code into person B's codebase. But they often don't want to commit at the end of the day for fear of breaking the build.
This led me to DVCS -- well suited to P2P merging and doesn't require "the big commit". A team member suggested that TFS's shelveset would be able to do this as well. How do the two approaches compare?
Team is currently using Subversion.
The TFS shelveset allows you to create something akin to a changeset, that isn't stored in the main repository. This shelveset is a backup, and can be "pulled" by another developer from another machine. This "private repository", and the ability to "pull" it is as far as the shelveset compares to DVCS. Shelvesets however are not true repositories; they are merely snapshots, they do not maintain history, and you cannot check in or manage changes as you would with the source control repository on your TFS.
A DVCS is a lot more than this; with a DVCS, you have a complete copy of the repository on your machine. You can commit locally as often as you want, storing each and every change you make; you can revert changes as much as you want, since your machine is for all intents and purposes, your source control.
And then you can push your changes to another machine (central repositor, build machine, or whatever). DVCS is a completely different and flexible paradigm, that allows but doesn't require the use of a central repository. It frees you of having to choose between stable and frequent check-ins (you can check-in locally whenever you want, and push when you're stable).
There's a lot more to it. If you like, you can checkout Joel Spolskey's excellent (and hillarious) intro to Mercurial DVCS at hginit.com.
Hope this helps,
Assaf.
There is a tfs-git solution. Git will allow you to do what you want, shape it to how you want the changes to read, then commit to tfs at the end of the day.
I would recommend switching to git anyway.