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
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.
At my organization, we'd like to switch from using CVS to Mercurial for a variety of reasons. We've done a lot of investigation when trying to determine how we should organize our Hg repositories based on what we have in our codebase and how we tend to work. We've come up with satisfactory answers to most of our questions, but there's one point that's stumping us a little, and it's driving me mad because the most convenient way to organize the repo for our workflow just seems like the wrong way to go from a conceptual standpoint. I'm trying to figure out whether our perception of how this is "supposed" to work is wrong, or whether we're just bumping up against a legitimate feature gap in the available tooling.
Primarily we maintain a medium sized codebase consisting of a suite of applications that get all get released in the same package. Conceptually you can divide our code into three categories:
Shared code
Application code for our primary suite (uses the shared code)
Miscellaneous small utilities that are infrequently maintained (uses the shared code)
This doesn't seem unusual to me, but I want to stress the point that we maintain the application code and the shared code at the same time and always want them to be bleeding edge with respect to each other. That is, we want all our application builds to always use the latest version and the same version of the shared code. We frequently add to or modify application code and shared code at the same time. Currently, the shared code is in one CVS module, and the applications are all in their own separate modules. The shared code and application modules are checked out such that the shared code gets built once and then linked into each application. We frequently do cvs commits that include changes across shared and application modules at once. We would really like to keep that ability.
I understand that commits in Hg are atomic within repositories -- that's fine but I'd like to be able to diff and commit to an application and a shared library at the "same time" (i.e. I don't care if it's really atomic but I don't want to have to manually do two separate diffs and two separate commit actions).
Conceptually, it seems like it would be correct to have one or a few repos for the shared code, and a separate repo for each application and each little utility program. This means you'd need to check out multiple repos for each build but that isn't a problem for us. The problem is there doesn't seem to be any tooling that lets you view updates or changes on multiple repos at once, or diff multiple repos at once and then sequentially commit them for you. This would be easy to script, but that wouldn't help developers who want to use various GUI frontends to complement the command line.
It seems like in order to be able to commit across multiple codebases at once (from a user's perspective) and keep everything on the bleeding edge together, the only two solutions are:
Use a monolithic repo with EVERYTHING in it.
Create some subrepos but access/commit everything through a big monolithic "main" repo that contains all the subrepos to keep everything on the latest revisions (which doesn't seem any better than (1) to me).
It can't be that unusual to want to work with multiple "peer" repositories at the same time, even if the actions aren't truly atomic across all of them -- and yet I'm not finding tons of articles or posts clamoring for this ability.
In summary:
We would like to organize our code such that we can diff and commit application code and shared code at the same time from the user's perspective (they need not truly be atomic).
It seems like we should be putting application code and shared code in separate repositories.
Subrepositories tie parent repositories to specific revisions, which we do not want.
What am I missing here?
In my shop, we have many projects that are simply in separate repos, but the main application's repo has 2 other projects in it. One is a module that shares a significant amount of code with the main application, and the other is for database migrations for the application (it's even in a different language). I wanted related changes in both the application and the migrator to be committed together, inseparably. Altogether, all source files in this repo are between 10 and 11 MB.
So if putting everything in one repository is really what makes sense because you don't want to deal with subrepositories, then there's nothing wrong with putting everything in one repository. The one of mine is on the small side of medium, in my opinion. TortoiseHg's source is around 20 MB, OGRE is over 100 MB.
Without knowing more about your projects and their relationships, the impression I get is that a single repository would work just fine, and that you're not looking at this incorrectly.
If you change your mind, hg convert can help you extract projects into their own repository, maintaining the history of those files.
If the one-repository approach is not for you, then I think subrepos should be given a chance, as that is the only other method I know of for treating multiple repos cohesively that is supported in TortoiseHg (see the Recommendations section).
However, I'm not sure how you would deal with the inter-department access, given that it doesn't seem there is an established subset already shared with others.
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'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!
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.