I am a very visual person and I'm having a hard time wrapping my head around Source Control.
It would be really cool if there were a visual representation of what all the pieces look like (central repo, local, etc.) during the process.
You might benefit from reading this: http://nvie.com/posts/a-successful-git-branching-model/
Yeah it's for Git, but the same branching model can be applied to hg, and it shows the some ways you can share code between teams.
Related
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.
I am an applied mathematician and I have recently joined a project that involves the development of production code for our scientific application. The code base is not small and it's deployed as part of a web application.
When I joined, the code was miraculously maintained without a revision control system. There was a central folder in a server and researchers would copy from it when they needed to work with the code. Inside this root directory there was a set of directories with different versions of the code, so people would start working on the latest version they found and create a new one with their modifications.
I created a Mercurial repository, added all code versions to it and convinced everyone to use it. However, since moving to Mercurial, we have felt little if any need to upgrade version numbers, even tough using hg copy allows us to keep revision history.
Here's where I need your advice on best practices of maintaining this code base. Does it make sense under a RCS to keep folders with different versions in a repo? If we keep a single copy of our code in the repo, what's the most common way to track versions? The README files? Should we keep snapshots of the code outside the repo specifying versions? Does it make sense to keep things as they are? What strategies do you use?
Our team is a bunch of scientists and no one has experience on how to maintain such a repo, so I'm interested in what is commonly done.
If you are going to use a version control system, forget about those version folders. Completly. Mercurial will do that for you, the repository is a complete history of all files of the project.
A common way to track version numbers is with tags. You assign a tag with the version number to a changeset.
To help you, as a "getting started guide" in version control, I suggest this book: Version Control By Example. It's free, and it starts from the beginning, it talks about CVCS, DVCS, fundamentals, what a repository is, basic commands, etc. It has also some interesting analogies, like the 3D file system: Directories x Files x Time. The book is fun and easy to understand, I highly recommend it.
I also recommend some GUI software like TortoiseHg. In daily usage, I spend most of the time in the console, but the GUI is very handy specially in the beginning when you still don't know all the commands. And the best part is the graph, you have a visual feedback of what is going on.
This is a good and quick introduction to Mercurial, it even starts out by talking about how using folders to keep different versions is not so great.
I think you're probably on the wrong track if you are using the hg copy command, I've never needed it ;)
The tutorial teaches the command line version of hg, which I personally prefer. When you need a better overview of your repository, you can run "hg serve" and open localhost:8000 in your web browser. I prefer that over TortoiseHG, but I realize that many people want a pure GUI tool.
I'm an hg user since a couple a years and I'm happy about that!
I have to start a project as I never did before.
The idea is to develop a software with a batch mode and an GUI.
So there will be common sources to both batch and GUI mode but each one will also contain specific sources.
And, basically, I would like my coworkers to be able to clone the GUI version, work on it an commit changes.
Then, I'd like to be able to merge their changes on the common files with the batch version.
How can I deal with that?
Since I've been reading a bit on this topic, I would really appreciate any help!!
Thank you.
binoua
As the creator of subrepos, I strongly recommend against using subrepos for this.
While subrepos can be used for breaking up a larger project into smaller pieces, the benefits of this are often outweighed by the additional complexity and fragility that subrepos involve. Unless your project is going to be really large, you should just stick to one project repo for simplicity.
So what are subrepos for, then? Subrepos are best for managing collections of otherwise independent projects. For instance, let's say you're building a large GUI tool that wraps around an existing SCM. I'd recommend you structure it something like this:
scm-gui-build/ <- master build repo with subrepos:
scm-gui/ <- independent repo for all the code in your GUI tool
scm/ <- repo for the third-party SCM itself
gui-toolkit/ <- a third-party GUI toolkit you depend on
extensions/ <- some third-party extension to bundle
extension-foo/
Here you do all your work in a plain old repo (scm-gui), but use a master repo at a higher level to manage building/packaging/versioning/tagging/releasing the whole collection. The master scm-gui-build repo is just a thin wrapper around other normal repos, which means that if something breaks (like one of the repo's URLs goes offline) you can keep working in your project without problems.
(see also: https://www.mercurial-scm.org/wiki/Subrepository#Recommendations)
I have worked with mercurial for some time now and it feels like a big asset to what I do. It's great to never mess up code again by accident.
I love the workflow and wants to setup versioning on all my projects. What is the best option of the two below illustrated alternatives?
Alternative A:
/repo/
/repo/ownWork/
/project1/
/repo/clients/
/client1/
Alternative B:
/repo/project1/
/repo/client1/
I don't think there is a "right" answer. As with many things, it depends.
Personally, I have a separate repository for each project and, possibly, one or more repositories for shared code. With distributed source control you have to check out/clone the whole repository, not just sub-folders like you can with, say, SVN. Therefore I like to keep each project/client as self contained as possible but, if necessary, clone shared repos too.
However, I still maintain a single 'central' web server to host them all. I like 'distributed' and I like 'centralised' too :-)
The good thing about hg is that it seems (to my newbie eyes, anyway) to be very easy to chop and change your layout/structure as time progresses.
In mercurial it's very easy to combine repos later, but not possible to separate them without invalidating existing clones. Start separate and merge later if it has become a hassle. Consider subrepos for code shared among projects.
My company is switching from Subversion to Mercurial. We're using .NET for our product. We have a solution with about a dozen projects that are separate modules with no dependencies on each other. We're using a central repo on a server with push/pull for our integration build.
I'm trying to figure out if I should create one central repo with all the projects in it, or if I should create a separate repo for each project. One argument for separate repos is that branching the individual modules would be easier, but an argument for a single repo is easier management and workflow.
I'm very new to hg and DVCS, so some guidance is greatly appreciated.
ETA: At hginit.com, Joel says:
[I]f you’re used to having one big
gigantic repository for the whole
company, where some people only check
out and work on subdirectories that
they care about, this isn’t a very
good way to work with Mercurial—you’re
better off having lots of smaller
repositories for each project.
It'd be great if someone could expand on this or point me to more documentation.
One thing you should take into consideration here is the fact that Mercurial does not support checking out directories like subversion does. One typical subversion setup is to have one giant repo with multiple separate projects in it, and when somebody needs code they will just checkout a subdirectory containing that project. You can't do this in mercurial. You either take the whole repo, or nothing. If everybody working on these projects does not need all the code, all the time, you might want to split it up into separate repositories.
EDIT: This link might be helpful in setting things up, in particular the "Publishing Multiple Repositories" section.
if completely separate repos don't work for you maybe have each project as a subrepo of some umbrella repo. I have to say that seperate repos sounds like what you need though given that each project sounds totally independent.
I'm fairly new to Mercurial myself (my company is making the leap from SourceSafe) so I don't know what more experience would say.
For me it makes sense to have one repository per Visual Studio Solution. If your modules are truly not dependent on each other, why are they all in the same solution? If you have a good reason for them all being in one solution, then that's probably the reason to keep them in one repository. If there's not a good reason for them to be in one solution, then a repository and a solution for each makes more sense to me.
Edit: So, since all the modules are built together and need to integrate, that would push me towards a single solution and a single repository.
Mercurial does a great job of merging, but the one thing I've had issues with is the solution file when merging the addition of more than one project at a time. It gets confused with multiple End Project lines. So, as long as you aren't adding new projects very often, your merges should be smooth.
From my experience, and not based upon studies etc, I would say that each logical blob is a repository. If you share code between subprojects, they need to be in the same repo. There will be full subrepo functionality, but currently (apr 2010) it's not fully implemented.