I'm working on a website that has been in production for some year now. Soon I will start working on a new version, and its initial repository will be a copy of the current site's repository. After the setup of the new repositories, the two repositories of the current site and the new site will diverge. However, if I fix a bug in the current website, I'd like to merge that fix into the new website.
Until recently I used TFS, which made it easy to merge two different versions of a repository (in TFS they're called branches), but how can I achieve this using Mercurial? So far, I've only found instructions on how to merge two different repositories with the intent of discontinuing the oldest repository.
Cheers,
Simon
I don't think there's a problem. You can just merge from the old site into the new site, and continue to do so for as long as you want.
Thanks for your reply, Djc. It appears that just after asking this question at StackOverflow, I found the answer myself at Mercurial's site: https://www.mercurial-scm.org/wiki/MergingUnrelatedRepositories
Related
I have starting using Mercurial for my (our) versioning needs. I have now come to the point that I need to create a feature branch. However, now that I have started working on it -- and I try to push my changes, I keep getting a warning about new remote heads. That's stupid, I know that there will be new remote head(s) that's what a branch after all is?
How am I supposed to create branches and push them without this problem, without using force push as it is surely not the right way to go, right?
I thought about using separate repositories, but that feels just stupid especially for feature branches.
Any help welcome!
To date, the best guide out there is Steve Losh's "A Guide to Branching in Mercurial".
Mercurial will always complain about creating new heads on the remote. You must use either --force or --new-branch when creating a new head.
When using TortoiseHg, the same can be accomplished via the Synchronize view of the Workbench. Click Options and then select the Allow push of a new branch or Force push or pull option, as needed.
The reason it behaves this is way is that the Mercurial developers wanted to make it a conscious decision to create a new head on the remote. Their view is that typical workflows should merge changes prior to pushing.
This tutorial by Joel Spolsky helped me a bunch when I just started out with mercurial. It might be helpful for you as well:
http://hginit.com/
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.
Does anybody have any advice about using Mercurial as a front end for Perforce? What I would like to do is to use Mercurial to handle really granular changes and then, once I'm done something, push it back up to the Perforce server.
I found this article http://www.dehora.net/journal/2008/01/05/using-mercurial-with-perforce/ but it doesn't suggest any tooling to help out with the integrations. Does any exist? I suppose I am looking for it pull any new changes from Perforce, integrate them into my local Mercurial then roll up all the Mercurial commits I've made since last integration and push them up to Perforce. Similar to git-p4.
I got an error when I followed the link you gave. But I suggest you look into the perfarce extension (I love the name!). I have not used it myself, but it's my understanding that this is what people use to bridge the gap between Mercurial and Perforce.
See also the wiki page on Perforce concepts. It seems to have a lot of good info.
As Martin says, Perfarce is what you want. I've used it at a previous job, and in general it works pretty well if you're just working with a single perforce branch into a single mercurial clone. If you start cloning multiple times from your original Mercurial clone, then things start getting complex. Not impossible, just complex.
In general it works by bundling all changes since you last pulled from Perforce. Creating a single perforce changelist from them. Tagging that changelist's comment with the hash of the Mercurial version and committing it to perforce. It then re-imports that change from Perforce and merges it into your Mercurial tree, and because they're both the same there's no merge.
Basically it works quite well for pull/edit/commit/update workflows. Unfortunately it's not any help when it comes to integrations (unless I missed something) as perforce branches aren't converted to Mercurial ones. It wouldn't know what to merge.
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.
Im in the process of trying to get my head round a dvcs such as mercurial. Im getting quite confused with certain points though. Firstly, a bit of context:
At the minute i mostly use subversion, and it works fine for my workflow,
Mostly the repository is for my own use, im the only web developer,and i only ever submit raw code to my manager, he never has to see the repository.
I use the repo to create major versions, and as backup so i can revert to it when something doesnt work out.
The repo also acts a file share, enabling me to work from the same codebase at work and at home.
My main reason for wanting to switch to mercurial, is the offline commits and easier branching / merging.
Firstly can anyone tell me how i would get mercurial to fit this workflow?
How do i go about sharing multiple repositories (i.e. one for each project) between computers?
Any help would be hugely appreciated,
Thanks
http://hginit.com/
There is a fantastic pre-chapter there specifically for SVN users. The rest of the tutorial will get you on your feet fairly quickly.
I'll answer just one part of your question, that of how to manage access to your repository from both home and work, because this is one of the situations where distributed version control is really useful.
The answer is that your two repositories are clones of one-another (to be correct, one is the clone of the other). You do some work during the day, check it in, then pull that work to your home repository (or push, but that requires more work). The next morning, you do the same thing in reverse. Mercurial comes with a built-in read-only HTTP server that makes it really easy, provided that you can expose a port.
The end result is that you have two repositories (ie, automatic backup of the entire history). At any given point in time, one is "better" than the other, but since you're the sole committer to both, they won't diverge.