I'm evaluating a version control system for our team (of 1 to 2 developers) and am wondering how TFS 2012 version control compares to Mercurial in terms of merging and branching. We don't have a large team and it might just be me and maybe another developer so we may not need robust branching/merging capabilities that a DVCS offers. I haven't been able to find much info on TFS 2012 version control in terms of its capabilities. Can anybody point me to a guide or highlight some features? Please note, that we only have access to standalone version of TFS 2012 on VS professional version.
Thanks
Mercurial branching differs from TFS in one critical way. Whereas TFS stores your branches in a different part of the filespace, Mercurial stores them in the history itself. This massively reduces the friction involved in branching and merging. It means, for example that:
Branches are created implicitly, simply by updating to a revision other than the latest, then committing on top of that.
Branches are also closed implicitly, again, simply by merging.
Branches can be re-opened implicitly, the same way as you create them in the first place.
Mercurial lets you switch between branches in-place very easily. You don't need to set up separate workspace mappings, and you don't need to change from one directory to another.
Branches can be anonymous.
Whereas TFS has "baseless merges" (which basically means it has massive problems with branches that aren't in a direct parent/child relationship), there is no such thing in Mercurial. It is always possible to find a common origin between two revisions, no matter how far apart their respective branches have diverged.
The graphical view of your branches in TortoiseHg is integrated with your project history, making it much easier to understand how branching and merging actually works in the first place.
There are several advantages of branching and merging which apply even to small teams or solo developers. One such example is being able to fix bugs on your production system even when you have other features in development. Another example is exploratory or experimental development: if one approach doesn't work out, you can easily roll back to the start and try a second, different approach, while still keeping the original approach around in case you need to refer back to it.
The previous "answers" are a little strange. Branching and merging in TFS 2012 works exactly like you would expect it to, with both a GUI and command line implementation. Here's a good document that covers the topic fairly completely:
ALM Ranger Guide updated
Preface:
I'm not related in any way with TFS and never used it
Face:
Newest 'tfs2012' question, at least some (How to set up TFS to cater multiple projects to multiple clients, TFS 2012: Correllating binaries to builds and source code, TFS 2012 Disable Multiple Check-out not working), demonstrate us problems, which I never consider even as question in Mercurial (with some added external tools sometimes). But you can understand also, that TFS positioned as full ALM-tool, not as pure SCM, which Mercurial is.
"Team Foundation Server is the Lotus Notes of version control tools" from James McKay is not freshest article (Feb 2011), but at least some statement are still valid, I think.
Amount of branching-merging will correlate to team-size only partially, mainly depends on the style of development, habits of developers
If you are in a small team, go with Mercurial without a doubt.
Mercurial is lightweight and flexible with regards to the specific development workflow you will use. It fits smaller teams much better, in fact, it even fits a solo dev because it does not impose any administrative overhead.
About the need for merging, it's really not an advanced feature as you imply: it is a very fundamental feature that most (all?) non-distributed VCS just can't get right. You might not need it now, but if you ever do, you'll have it right there in Mercurial and it just works.
Related
We are switching to Mercurial. We are have been using SVN for a number of years. I recall reading somewhere that Twitter only have two branches in their source control. A production branch and a dev branch. This I think will suit us because we offer a service and there is only one instance of it running and we control it completely so we dont have to worry about versions. Just bring able to do fixes for production and maybe merge that change into dev if the issue exists in the dev branch too.
Is this approach appropriate for Mercurial? Are there any hidden gotchas that we should be aware of? We plan do follow a more traditional layout with release branches for the one or two products that we have that we retail.
Yes, no gotchas. The most recognized branching model, for both Git and Mercurial, can be found here, which gives an outline of a more complexe structure than you are thinking of using.
And even when your environment continue to grow, mercurial will still be able to handle your changing needs.
Are there any hidden gotchas that we should be aware of?
Yes, they are, if you will have more than one simultaneous tasks in devel you'll get hardly readable and understandable history with a lot of anonymous branches in devel rather fast
Yes, Mercurial achieves fully your approach. May be the workflow you are proposing is this. The Mercurial code or the Python code are some examples of development with really few branches.
In Mercurial the default branch is used as default when cloning, so is usually used as the development branch. Other branches are used as feature or stable branches, but is up to you. Actually for not so long features and issues one may use bookmarks on the development branch.
And remember to commit often :)
We are using Mercurial to manage a project, but we now want to create a "Lite" version of the same project (ie a version with some of the functionality removed or simplified).
Since the Lite version will share most of its code with the Full version, we are considering whether it is better to either:
Create a clone of the original project and keep each project separate.
Use named branches to maintain both versions of the project within the same repository.
We are fairly new to version control software and this will be the first time that we have used named branches. Can someone please help outline the pros and cons of each approach. Which approach would make it easiest to maintain bug fixes between the two projects?
Thanks,
Andrew
You can use any of 4 methods - they have more or less the same amount of functionality and differ only in used commands for syncing codebase
For "Separate clones" solution "...keep each project separate" is Bad Thing (tm) and violation of DRY principle: re-used code (Lite version) must be maintained in single place and changes in core pulled from Lite repo to Full repo
Note:
When I wrote about 4 solutions, I had in mind, except clones and named branches also
MQ (Lite version is changesets in repository, Full version is MQ-patch(es) on top of Lie in the same repo
Subrepositories|Guestrepo (Lite version is superrepo, Full version functionality is one or more subrepositories in superrepository)
Having the same problem, I stumbled across this question. Now I found a solution which I'd like to share with you.
Suppose we have two devices, A and B, both having essentially the same firmware, but with certain differences which are supposed to be retained. Thus the two versions are retained in two branches - A and B.
If I make now a change at one of the versions, I can merge them over to the other one under certain conditions.
The condition is that the common precedessor (common base) must be of the "giving" branch.
In order to ensure this, you can do
hg debugsetparents . <other branch before the modifications>
After doing this, the current working set is like a merge of two branches, except that the data remains stable, i. e. "we" keep "our" stuff.
After this, you can do a "real" merge with the other branch after the modifications.
The result of doing so is that you get exactly the difference between the manually-created common base in the giving branch and the final state of the giving branch, resulting in exactly the modifications you want to get.
I am currently using Mercurial, along with the Guestrepo extension, to manage and version the different components of a project. I have come to a quite stable workflow to manage the different versions of the components.
However, I can't come up with an effective solution when it comes to versioning subtle variations of a component. This is, for example, a slightly different embedded device driver (different serial port speed for example), or a GUI which is written in English instead of German.
I don't think stacking them in the Release/Stable branch is a good workflow, as the proliferation of different configurations (English,Spanish,Chinese,...) could lead to a serious and nonsense bloat of the Release branch.
On the other hand, creating a separate Release branch for each, would lead me to many, many branches, which is not the best solution IMHO.
Creating separate repositories for each of the configurations would suppose a quite tedious task whenever a structural change had to be made, as all of the repos would have to be updated with that change.
Any idea on this?
Thank you.
As #EldadAK suggests, creating a repo for each configuration and importing core functionalities from other repos seems a nice idea.
However, I still can't figure out how to arrange "same but slightly different" components, which differ in some subtle features but share their core.
Is it a code architecture issue? Should the components be refactored so that the main core and the differing features lay in different components, which are related using custom builds for each configuration?
IMHO, you should keep all changes in your main branch. Managing all branches or even multiple repositories is not scalable and will eventually get out of hand.
I don't think you should care about the size of your release branch. By keeping it all together, you will always know where you are, what is included in a release and when you really need to branch, have all the changes accumulated to that point.
It's my personal opinion that you should try and keep it simple to manage looking many revisions and years ahead...
Note - Project managers tend to think about next week. You need to think about next year...
I hope this helps.
effective solution when it comes to versioning subtle variations of a component
While I can't see any serious drawbacks from using named branches in one repo, you can use another ("default" de-facto) solution for configuration management inside Mercurial: MQ
You have only slightly adopt your workflow (same amount of branches, same amount of repos) to MQ
Currently, we're using Mercurial as our VCS on BitBucket.
The way the project is right now, is a solution with all the code checked in with all the developers working on the "default" branch. Every morning, we create a build release and the QA have it.
I'm wondering whether it makes more sense to branch each dev on his own since each dev is working on a project in the solution.
The other main point is how would this affect the QAs? Would they need to merge all the branches prior to building?
I'm really confused about this.
As mentioned in "When should you make a branch", you use branching to isolate a development effort.
In your case, you would isolate each project in the solution on which you are working.
That would allows for:
intermediate commits, project per project
QA testing for each project
But that would also require a merge in a common branch for all the project to be tested together as a solution.
See HgInit (from Joel Spolsky) for more on that kind of collaboration workflow.
In "Repository Architecture", Joel illustrates two development effort isolated in two different teams, but still including a synchronization (merge) effort at the end.
My company's product is module-based, meaning we ship with five base modules and users can purchase additional ones. We're using Mercurial, to which we are relatively new, for our source control, and since we've released 1.0 of our product, managing the separate module development has been a nightmare.
We want to be able to release minor bugfix updates without having to wait for particular module development to be complete, so one repo for everything doesn't work very well. I read about branching but the Definitive Guide seems to suggest that branching is temporary, and that merging with it is difficult.
Ideally, we'd have a base repo that is the product and then different repos (or branches) with the extra modules, so that QA could build the main product and the main+addons separately, while the developers working on ModuleA don't impact the developers working on BugfixB. I tried this with multiple subrepos but it ended up corrupting my repositories.
Should I be looking at using named branches? Or bookmarks?
I'm looking for suggestions on best practices on how we can take advantage of Mercurial's features to make this process easier.
Thanks!
There is a good tutorial about branching at http://nvie.com/git-model. The main point is to have
a release branch which contains only merges from completed release/bugfix branches
development branches for bug fixes or features
own branches for long-term features
Also there is a reference about the technical differences in mercurial branches at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
Branching is your solution. I consider named branches to be a Good Thing. However, you should be aware that named branches require a certain level of forethought and discipline in use.
I would suggest that each bug-fix gets its own branch. Developers will fork off that branch, do the bugfix, merge back into the feature-branch.
I would consider splitting your modules into separate repositories, one for each product. Possibly that's not very useful; you'll have to go over different use cases there and determine how the workflow/compile-flow would go.
I don't see why you'd consider having different subrepos for this when the file history is virtually the same throughout - this is a prime job for branches. The only complication is being able to cherry-pick patches for each branch - that may require you to export a patch (or set of patches) and apply them individually to each branch. It's a bit more awkward than it should be, but it's no harder than doing the same across different repositories.
I think the question blurs two different issues:
You have a modular product
You have separate development cycles for each module
For handling the modular product you should use different repositories for each module and bring them together using subrepos as appropriate for each customer configuration. It appears you're already doing this but are having corruption issues. This is certainly the correct way to go so you need to bottom-out whether the corruption is coming from a Mercurial bug or user error.
For handling separate development cycles then personally I'd go for module clones but named branches would also be fine.
Hope this helps.
I am new to Mercurial as well, but I think that your problem is not specific to it.
You need to think about the process of releasing code and the parties involved, and map this model to a branch layout that can support it.
Mercurial is nice because it can support developers well, by allowing them to maintain their own development "branches" without affecting a continuous build or other downstream processes (QA, installers, etc).
[Rel]
^
[RC]
^
[QA]----[QA]------[QA]
^ ^ ^
[Dev]---------------------------------------------------------
^ ^ ^
[Jen] [Paul] [Ken]
this is a possible scheme, where developers merge to Dev, and somebody merges regularly to the [QA] branch, and when that it baked nice goes to [RC] etc.
Every release stays isolated from other activity.
Good Luck!