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.
Related
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.
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.
The Microsoft ALM Team describe the Basic Branch Plan as needing a MAIN, DEV, and RELEASE branch.
I am working on introducing branching/merging to a new team who currently uses source control with no branches whatsoever.
I was wondering how the RELEASE branch is actually used.
Can changes be made in the DEV branch then be merged up to the MAIN branch without needing a RELEASE branch? MAIN would still be read-only. It would basically be the RELEASE branch in essence. The reason I say this is because we don't have that many changes but I want to isolate the stable code from new changes. Our concept of a "release" per say is not yet well defined. I am still working on that.
I just don't know if my team needs a RELEASE branch (considering our needs specifically).
I would appreciate some comment about the strategy of just having a MAIN and DEV branch.
Typically the release branch(es) are used for "safekeeping". Basically the same as a label.
Releases to production are usually a pretty important event, and you want to know exactly what source you released (in case you ever need to go back to it). Way back when people used to create Labels to track this, but creating Release branches is better for a couple reasons:
Labels are mutable in TFS, meaning somebody could change a label and there would be no audit trail
Branches are also mutable of course (changes can be checked in), but this can be locked down via branch specific permissions
Also if a change is made to a Release branch (which it never should be), at least you have an audit trail through history
Even though a branch looks like a heavy-weight operation creating a copy of your entire code base, in reality TFS just creates a new pointer to the same files, so the storage cost is trivial
I went the other way when I implemented TFS at a client (replaced SVN). What I did was introduce a MAIN branch and a RELEASE branch and not a DEV branch initially as that seemed very confusing to the team. It is also hard to convey the purpose of a DEV branch to an SVN familiar team initially.
The main purpose of our RELEASE branch was to preserve a historical placeholder as said in another answer. Currently we are using Git and we have a CI server that does the release process and branches to release/$version_number. I think that concept might be easier to understand and convey to your team. i.e. automatically create release branches when you actually release.
In TFS, if you want to create a personal branch to try out an idea you
have, you will have to create a branch on the TFS server – even if no
one else needs access to your code. And when you create this branch,
every single file in your project will be duplicated – even if your
branch has very few changes compared to the original one. Now you’re
using twice the amount of disk space both on the server and locally!
Is this true, and one of the downsides of a non-distributed VCS?
Both statements are wrong. (Where did you read this?)
In TFS, if you want to create a personal branch to try out an idea you have, you will have to create a branch on the TFS server
No you don't always need a branch if you're just "trying out an idea". Of course it depends on what you want to do. Saving your work on the server to secure it against drive crashes is what shelvesets are for in TFS (other VCSs may not provide anything similar, which is why you need to create a branch for every idea there). You can even share your code with others without actually checking it in using shelvesets. Even a simple kind of versioning can be done by including the timestamp in the names of the shelvesets, but this is tedious, probably more so than creating a branch ;) Building your code on the server is another thing you can do with shelvesets.
You should read up on when to use shelvesets over changesets on MSDN (there is an article somewhere) to decide whether you need a new branch.
Now you’re using twice the amount of disk space both on the server and locally!
The copying of the code only happens virtually. The SQL Server behind the TFS Server will not use up twice the space, unless every file actually changes on either one of these branches. Until then, both files on the two branches will "point" to the exact same memory on the SQL Server. If you need to work on both branches simultaneously and map them into your workspace, then of course you need twice the amount of space locally. Both is true for any VCS I am aware of, so this is not a TFS-specific issue.