I am a newbie currently trying to patch bugs in Firefox using Mercurial, Arcanist and Phabricator, but I'm having an on going issue that I can't figure out. Every time I create a new revision, All of the patches from my previous commits attach themselves to my newest revision. My basic workflow is listed below:
From /c/mozilla-source/mozilla-central:
After making a change in the source code, I then commit my changes. For example:
hg add /path/to/file/changed
hg commit -m "Bug 1234567 - Implement feature XYZ. r=name,name2!"
Then I create a revision in Differential, using Arcanist:
arc diff
I feel like I'm missing a step either at the beginning of the process or at the end, do I need to clean up or clear out something after creating a revision in Differential using arc diff? I noticed when I do run arc diff and my editor opens to have me fill in info, the text file template is already filled with data from the old commit messages. So it seems to be automatically attaching these old patches for some reason.
Any guidance would be greatly appreciated,
J
Related
We have an Hg repo that is over 6GB and 150,000 changesets. It has 8 years of history on a large application. We have used a branching strategy over the last 8 years. In this approach, we create a new branch for a feature and when finished, close the branch and merge it to default/trunk. We don't prune branches after changes are pushed into default.
As our repo grows, it is getting more painful to work with. We love having the full history on each file and don't want to lose that, but we want to make our repo size much smaller.
One approach I've been looking into would be to have two separate repos, a 'Working' repo and an 'Archive' repo. The Working repo would contain the last 1 to 2 years of history and would be the repo developers cloned and pushed/pulled from on a daily basis. The Archive repo would contain the full history, including the new changesets pushed into the working repo.
I cannot find the right Hg commands to enable this. I was able to create a Working repo using hg convert <src> <dest> --config convert.hg.startref=<rev>. However, Mecurial sees this as a completely different repo, breaking any association between our Working and Archive repos. I'm unable to find a way to merge/splice changesets pushed to the Working repo into the Archive repo and maintain a unified file history. I tried hg transplant -s <src>, but that resulted in several 'skipping emptied changeset' messages. It's not clear to my why the hg transplant command felt those changeset were empty. Also, if I were to get this working, does anyone know if it maintains a file's history, or is my repo going to see the transplanted portion as separate, maybe showing up as a delete/create or something?
Anyone have a solution to either enable this Working/Archive approach or have a different approach that may work for us? It is critical that we maintain full file history, to make historical research simple.
Thanks
You might be hitting a known bug with the underlying storage compression. 6GB for 150,000 revision is a lot.
This storage issue is usually encountered on very branchy repositories, on an internal data structure storing the content of each revision. The current fix for this bug can reduce repository size up to ten folds.
Possible Quick Fix
You can blindly try to apply the current fix for the issue and see if it shrinks your repository.
upgrade to Mercurial 4.7,
add the following to your repository configuration:
[format]
sparse-revlog = yes
run hg debugupgraderepo --optimize redeltaall --run (this will take a while)
Some other improvements are also turned on by default in 4.7. So upgrade to 4.7 and running the debugupgraderepo should help in all cases.
Finer Diagnostic
Can you tell us what is the size of the .hg/store/00manifest.d file compared to the full size of .hg/store ?
In addition, can you provide use with the output of hg debugrevlog -m
Other reason ?
Another reason for repository size to grow is for large (usually binary file) to be committed in it. Do you have any them ?
The problem is that the hash id for each revision is calculated based on a number of items including the parent id. So when you change the parent you change the id.
As far as I'm aware there is no nice way to do this, but I have done something similar with several of my repos. The bad news is that it required a chain of repos, batch files and splice maps to get it done.
The bulk of the work I'm describing is ideally done one time only and then you just run the same scripts against the same existing repos every time you want to update it to pull in the latest commits.
The way I would do it is to have three repos:
Working
Merge
Archive
The first commit of Working is a squash of all the original commits in Archive, so you'll be throwing that commit away when you pull your Working code into the Archive, and reparenting the second Working commit onto the old tip of Archive.
STOP: If you're going to do this, back up your existing repos, especially the Archive repo before trying it, it might get trashed if you run this over the top of it. It might also be fine, but I'm not having any problems on my conscience!
Pull both Working and Archive into the Merge repo.
You now have a Merge repo with two completely independent trees in it.
Create a splicemap. This is just a text file giving the hash of a child node and the hash of its proposed parent node, separated by a space.
So your splicemap would just be something like:
hash-of-working-commit-2 hash-of-archive-old-tip
Then run hg convert with the splicemap option to do the reparenting of the second commit of Working onto the old tip of the Archive. E.g.
hg convert --splicemap splicemapPath.txt --config convert.hg.saverev=true Merge Archive
You might want to try writing it to a different named repo rather than Archive the first time, or you could try writing it over a copy of the existing Archive, I'm not sure if it'll work but if it does it would probably be quicker.
Once you've run this setup once, you can just run the same scripts over the existing repos again and again to update with the latest Working revisions. Just pull from Working to Merge and then run the hg convert to put it into Archive.
I've recently started to work on an open source project which uses Mercurial.
I'm a new user to Mercurial, so I read the HG book and started working.
My goal was to write code and always pull and merge changes from the upstream
so I can stay up-to-date. The area that I am working on is also under heavy
development by others so I do want to merge my changes after a long period of
time. I cloned a repo. So, my workflow is like this:
I created a bookmark mybook
hg up mybook
Write code
3.1 hg commit -m 'new functions'
hg up default
hg pull
hg update
hg up mybook
hg merge default
Go to step 3.
In my mind this is the simplest workflow that allows me to stay up-to-date. I
also have only one HEAD because I always merge.
Since I am not a contributor yet, I am not allowed to push changes to remote
repo.
Recently I wanted to show my work to a project lead and he said send me a patch.
And this is where I am stuck. hg out shows 10 changesets. First of which
appeard already a month ago. They're numbers are 3341, 3342, 3345, 3346, 3349, 3356, 3360, 3365, 3366, 3368. The changeset numer 3368 is the tip.
I've recently read the chapter about the MQ extension. And this extensions seems to be what I need. But the problem is that I wrote code without using the MQ
extension.
So, how can I make use of the MQ extension on already created changesets so that
I can make a patch to send to the project lead so that he can apply it and see
my changes?
I've just issued hg qinit. What's next?
Issueing hg qimport -r 3341 gives
abort: revision 3341 has unmanaged children
Reading the book and googling further does not help me. I need an advice.
PS I've tried not using hg and MQ at all: simple diff -urN old/ new/ but I
want understand how to do it with the MQ.
Thank you.
Yeah, don't use MQ. It's a parallel system, meant for keeping things out of the history, and more important you don't need it.
You were asked for "a patch", not a complete history of your work, so I would recommend sending it in the form of a single before-after diff. hg export will give you a series of diffs, for all the work you've done, including the merges. I find it's far easier to read and review a single diff (before applying it). But instead of plain diff, use hg diff which knows to only look at tracked files, and has a number of other nice features (including the --git option, which provides richer metadata). This should do it:
hg up mybook
hg diff --git -r default > mywork.patch
Before sending it off, do an hg up default and apply the patch to check that it works without conflicts. And mention to the recipient which version of default you are patching against.
Edit: As you can read in the comments, #LazyBadger is a fan of the step-by-step patch generated by export. I prefer the single-step patch
since my history is usually TMI: Nobody cares about all the times I added a forgotten file, or noticed a bug too late and fixed in in the next commit, etc.
Take your pick.
I recently let the IDE replace a trivial text in the entire project, and recognized that mistake only after committing other changes to Mercurial. I panicked and (knowing very little about Mercurial, now after having read the definitive guide starting to get to know it better) tried every command that seemed to make my mistake "go away". It goes without saying that this was a move I am not proud of.
Of the things I remember to have tried was hg update tip and hg rollback. Since I'm using Mercurial on my local machine only and do not pull or push from any other repository, I think these commands did not cause my main problem: There are a lot of files missing now -exactly the files I let the IDE make the wrong replacements in.
What bothers me is that I have done hg status --change REV to find all files changed in a revision, and the deleted files do not show up there.
PHPStorm has a local history, which shows which files are now missing. That (only that?) enables me to hunt down the individual files and revert to their last known revision:
hg log -l 1 path/to/foo.txt
hg revert -r <my revision> path/to/foo.txt
... but that is way too time-consuming for the hundreds of files that got changed. Please tell me there's a better way. The PHPStorm history is nice and can restore the files as well, but it will restore them to the point where they had already been erroneously changed.
Your help is greatly appreciated, and I vow to learn & appreciate Mercurial as more than just a context menu item starting today.
If you are willing to lose the changes that were committed with or since the error, you may be able to go back to the revision just before the error, and start working from there. Use hg log to find out which revision you need, and hg update --rev XX to go to that revision. If you're not sure which revision you want, update to various revisions and take a look.
Once you have updated to the correct revision, you can just continue working from there. The next time you commit, you will automatically create a new branch on which you'll be working, which will not have the error in it. If you want, you can go back to the original branch and close it.
You might even be able to get back any correct commits that happened after you committed the error up to the revision you rolled back to. On the old branch, identify the revision after the error, and do a diff between that revision and the tip of that branch. Then, see if you can apply the diff as a patch on your new branch. You will still lose any changes that were in the same commit as the error, though.
Ok I've had a little google and can't find a solution as i've stumbled across the same message but different ways in which people have got it. I'm new to mecurial and want to make sure i'm doing this correctly.
So i'm getting the error message as above. I have a dev site and a live site and i'm trying to push the code to codebase.
However yesterday I accidentally did hg add which added all the media which i didn't want to do. I did revert after to remove all the media files from codebase, by then committing and push the changes. So today i've been making changes to the CSS file and a few templates. I've gone to commit my changes and push them but when i run hg push I get the error above.
I've run hg log and there are only 6 commits as it's a clean/new branch/project. Any help would be much appreciated and I apologize if i've not explained anything correctly!
This isn't an "error" message; it's a totally normal situation. That message is saying "hey, other people pushed new work to that repository while you were doing your work, you should probably integrate theirs into your so they don't have to integrate yours into theirs?"
So first do a:
hg pull
and then a:
hg merge
Incidentally the revert you did if you actually used the hg revert command didn't remove those files from history, so your history is probably pretty big.
Consider reading the first few chapters of the Mercurial book it covers these situations quite well.
If you want to cancel your conflicting changes
hg outgoing
You should see lines containing your commited/conflicting changes which are not pushed. Search for the changeset revision. Here 64
searching for changes
changeset: 64:1830948c246e
Then
hg strip 64
This worked for me.
hg push -f
For more command, try
hg help push
On TortoiseHg you can do this:
1 => Commit your files
2 => Go do your new branch, where you want to push your code
3 => On this branch, run Merge with develop
4 => Push your code whithout errors!
If you are using the Workbench to push the changes you can try the Detect outgoing changes first, See the attached Image
This will give you info on what is you are going to push.
My issue was, i had an old draft pending to be pushed. I was able to continue with the push once i have done strip on the old draft.
I'm working in this file and I come across a piece of code which I think has changed at some point in history, and I would like to know where it changed.
It's a pretty big file with a lot of history, so when I use hg diff, I get a enormous list and I don't think it's efficient to search through that.
It would be really neat if I can look into an old revision of the file, to see what the file looked like at a certain point in time. Then I can see how the code worked back then so I can conclude how the bug evolved. Of course, I want to do this without updating the file, because I'm currently working in it and have made changes in it.
So, is there any way you can look into the history of a file without updating it?
There are a few tools to help you:
To get the history of a file you can just use hg log FILE which is probably the best starting point.
You can also use hg annotate FILE which lists every line in the file and says which revision changed it to be like it currently is. It can also take a revision using the --rev REV command tail to look at older versions of the file.
To just list the contents of a file at a given revision you can use hg cat FILE --rev REV.
If it proves too hard to track down the bug using those tools, you can just clone your repository somewhere else and use hg bisect to track it down.
hg bisect lets you find the changeset that intoduced a problem. To start the search run the hg bisect --reset command. It is well document in Mercurial: The Definitive Guide.