Is there a way report the differences between changesets and branches?
For example: What files changed between the development branch and the testing branch or between changeset 1 and 2? This information is used in a software version description for an inventory of software. Thanks
I am new to Mercurial so have limited knowledge. We use Tortoise HG and I see no reportig functions at all.
Yes,
hg diff -r changeSet1:changeSet2
or if you want to see list of files that changes:
hg status -r changeSet1:changeSet2
Related
I am working in branch A and am using eclipse mercurial plugin to manage version control.Mistakely while pulling and updating the changes from the remote repository I pulled and updated changes of all the branches of my project.Now my branch A has changes of other branches say B , C , D .. as well.
I go-ogled and found out that hg rollback is likely the solution however I am not sure.
How do i undo my last pull and update? Any suggestion would be appreciated.
For a direct hands on How to revert a Mercurial hg pull?. Also look the Mercurial FAQ (7.13).
The hg update is never a problem, just do hg update YOUR_LOVED_REVISION_NUMBER and your working directory is again with all your stuff, and only your stuff.
Assuming you and only you works in the A branch, the hg pull is either a problem, just other's work in other's branches in your backstaged Mercurial internal history. If you like your history (DAG) clean then you may hg strip those annoying branches in your local repository.
Assuming the A branch is co-worked, then the hg pull just imported the other's work to your local copy of the project.
I have two Mercurial repositories that are for different major revisions of the same project. The latter version is a massive change to the functionality, and especially the UI, of the project, but it will still have a lot of common code with the earlier version. (For shorthand I'll call these versions 4.6 and 5.0 and the repositories project-4.x and project-5.x going forward; that's basically what I'm dealing with.)[1]
As we thought more carefully about the structure of our repository, and thinking especially about how to handle the related code, it became apparent that we wanted to simply pull the repositories together and used named branches for the ongoing work in each (from which people can branch or bookmark and merge as necessary). To do that, we decided we basically need to pull the project-5.x repository into the project-4.x repository. From what I can see, combining the repositories should be fairly straightforward:
$ hg pull -f project-5.x # in project-4.x
$ hg merge
So far, so good. My concern is handling the branching issue.[2] These are going to come in as two completely unrelated chains (which is fine), but I'd like the branch structure to look something like this:
---4.6----- }
\ } original project-4.x
5.0----- }
/
------- } original project-5.x
The problem is, I'm not exactly sure how to do it.
Edit: See below; the answer I devised worked.
Footnotes
If you're wondering why this is only coming up now… well, the project only got version controlled as of starting 4.6. Which, yes, is a little bit crazy. And I'd never been in charge of a major version change like this before, so I decided originally to make a new repo entirely, which I of course now regret. Live and learn.
Answers I've already read on the subject (but which left me unsure how to do this exactly):
Mercurial - merging branches
How do I merge two Mercurial repos into a single one
How can I import a mercurial repo (including history) into another mercurial repo as a subdirectory, without using subrepos?
I originally thought I'd need some way to pull into just the branch, but after chewing on it some more, I concluded the best way to do this is roughly as follows:
Create the desired new branch structure (i.e. create the 4.6 and 5.0 branches).
Remove the old default branch into the 4.6 branch in the base repository.
Pull the project-5.x repository into the project-4.x repository.
Merge the default (or in the case of this repository, experimental) baseline, which is pulled in during the merge, into the 5.0 branch, closing out the experimental branch along the way.
Restrict write access to the old repository's central push/pull location; we still have it for historical reasons, but people can't accidentally push to it.
Preparation (steps 1–2)
$ cd <project-4.x directory>
$ hg branch 4.6
$ hg ci -m "New 4.0 baseline"
$ hg branch 5.0
$ hg ci -m "New 5.0 baseline"
$ hg up default
$ hg ci --close-branch -m "Close default branch going forward.
$ hg up 4.6
$ hg merge default
$ hg ci -m "branch merge default -> 4.6"
At this point, the repository is set up: it has the new baseline branches and has removed the old default branch we wanted to get rid of.
After this, I made the changes to get the repository structure looking more the way it needed to for the 5.0 branch in the project-4.x repository (since massive restructuring is part of the version change effort).
Repository merge (steps 3–4)
The next step was actually merging the repositories together and pushing the content from the old repository into the desired branch.
$ hg pull -f <path to project-5.x repository> # still in project-4.x repository
$ hg merge -m "Merge in project-5.x repository"
$ hg up experimental # experimental is the name of the "default" branch
$ hg ci --close-branch -m "Close experimental branch"
$ hg up 5.0
$ hg merge experimental
$ hg ci -m "Merge old experimental into new 5.0 baseline"
This proceeded perfectly, with no merge conflicts whatsoever (except that I needed to resolve some small differences in my .hgignore file).
In Git it is easy, because remote/branch is pointing to a different commit than branch. How to do it with Mercurial?
If you mean seeing what's different between your local repo and the one you're pushing to, try
hg outgoing
Since Mercurial 2.1, there is also a purely local solution: phases. The draft phase is probably what you are looking for. For details, refer to:
https://www.mercurial-scm.org/wiki/Phases
You may find hg phase <rev> and hg log -r "draft()" interesting.
There is an remotebranch extension that will give you a Git-like setup. It tracks the remote heads for the repositories listed in the [paths] and exposes them as tags named <path>/<branch>. This lets you run
$ hg diff -r foo/default
to see what has changed since the default branch in the foo repository. There is also new revset keywords that let you do things like
$ hg log -r "not pushed()"
to get what
$ hg outgoing
would do, but without any network traffic.
What's the command line call to show all revisions in the draft phase?
hg log --style phases
That will display the log + the phase, since Mercurial 2.7 (2013-08-01).
I'd just use hg outgoing as others are suggesting, but hg summary will tell you too. It may require the --remote option to have it check the remote default server.
If you need to select the changesets for further processing, then you can use the outgoing revset predicate. This lets you re-implement hg outgoing as
hg log -r "outgoing()"
but the real benefit is that you can use this in other contexts, such as
hg strip "outgoing()"
Currently my company is using cvs for version control. We have an old branch of code which has been used specifically for one client (don't ask) that we'd like to merge to the head.
Due to the delta between this branch and the head I think the merging capabilities of mercurial should make my job a bit easier. My line of reasoning is:
Create mercurial repositories of the branch and the current head.
Do a merge of the branch repo to the trunk repo.
At this stage I'm expecting mercurial to provide better merge support than cvs.
Then I would commit my changes to the trunk repository back into cvs.
Is this approach sound? Will this strategy result in a less painful merge as I think it will, or is there something I'm missing?
The reason Mercurial merges better than CVS or Subversion is because it tracks the most recent common ancestor of the two heads/branches, so you'll to make sure you're providing that information accurately or you'll probably end up with a worse merge.
If you do something like this:
hg init newrepo
cd newrepo
cvs checkout POINT_OF_DIVERGENCE
hg commit --addremove -m 'commiting point of divergence'
cvs checkout BRANCH
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'committing branch head'
hg update -r 0 # jump back to point of divergence
cvs checkout HEAD
hg addremove --similarity 90 # let Mercurial discover any renames
hg commit -m 'commiting HEAD head'
hg merge
then the common ancestor for the two heads will be the point of divergence (sorry if the CVS commands are wrong, it's been a mercifully long time).
The trouble is knowing where the POINT_OF_DIVERGENCE is in the CVS repo -- CVS doesn't keep track of that at all, which is why its own merge doesn't use it.
CVS best practices always suggest that whenever you branch you create a tag that marks the point of divergence, but if you didn't do that then there's some tricky hunting ahead of you.
Without a correct most recent common ancestor the Mercurial merge won't be any better than CVS's.
Yes, that should work but there might be tiny little problems along the way (like how to get the source from CVS into Mercurial: Using hg convert or doing a manual import of a certain revision, etc).
Please create a new question if you run into a problem.
The built-in convert extension won't do well with CVS except for very simple histories. Use the fork of cvs2svn called cvs2hg
http://hg.gerg.ca/cvs2svn
We're using Mercurial where I work and I want to have a setup similar to how I used SVN:
Trunk
Tags
Production
Branches
Since Mercurial supports branches natively, I know how to create a named branch, but I can't find any documentation on how to repeatedly merge 'Trunk' with 'Production'.
Quite simply, I want to have a development branch for normal work and a production branch that I routinely pull changes from the development branch into. How do I do this with Mercurial?
As the previous poster mentioned, the transplant extension can be used for cherry-picking individual changes from one branch to another. If, however, you always want to pull all the latest changes, the hg merge command will get you there.
The simplest case is when you're using clones to implement branching (since that's the use case Mercurial is designed around). Assuming you've turned on the built-in fetch extension in your .hgrc / Mercurial.ini:
cd ~/src/development
# hack hack hack
hg commit -m "Made some changes"
cd ../production
hg fetch ../development
If you're using local branches:
hg update -C development
# hack hack hack
hg commit -m "Made some changes"
hg update -C production
hg merge development
hg commit -m "Merged from development"
Something like hg transplant? That's what we use on our dev and prod branches.