I'm using Mercurial locally, and pushing to bitbucket.org. I'm the only person working on this (private) project, and it's almost entirely on this computer, though there are one or two other computers that I've worked on it (ie the server). This error message is mysterious to me, and there is almost nothing about it on google. It is similar to the error you get when you haven't pulled/merged, but I have nothing to pull, nor to merge.
What is the cause of this error, and how do I fix it?
As lothiraldan pointed out in a comment, it's actually because I am using a weird version of Mercurial internal to my company.
Related
First things first, I'm a total moron for even being in this position at all. Newish dev with < 2 years experience and not a lot of time with version control, much less hg and tortoisehg.
I wanted to revert a merge, so after several failed attempts to create a new branch from my last good commit and merge it back into my local branch, I discovered the rebase extension could strip back to a good commit. (That said, since I had already pushed my bad commit, it didn't really solve my problems).
I went ahead used rebase > strip a few times nevertheless, and now tortoisehg hangs whenever I try to update.
hg cli still works, it's just tortoisehg that I seem to have broken. Tried uninstall/reinstall of tortoise, no luck.
I find that other guys in the office can pull and update without problems, so it's strictly a local problem.
Any suggestions on how to restore functionality? Thanks in advance.
I ran another uninstall using ccleaner, and then did a search for anything related to tortoise in my C:/ drive. Renamed every entry I could find (mostly in AppData/Roaming) and then reinstalled thg. Successfully updates and does everything else as usual now.
Background
Mercurial now has Phases which are a great mechanism to keep people from altering history that should not be altered. When a changeset is pushed to remote repository it is made public and can no longer be rebased. This is normally a good thing, if the repository is public and you don't want others altering your changesets.
However, if you have your own temporary repository for sharing draft changesets only with yourself, it can get very annoying. Mercurial has a option to turn this off. Adding this to the .hg/hgrc file of the remote repository.
[phases]
publish = False
This will prevent changesets pushed to the remote repository from moving from draft phase to public phase (both the local changeset and the one just pushed to the remote repository. However, pulling this changeset down still will always pulls it down in the public phase.
Question
I am hoping to pull down changesets in the draft phase. I simply want to push a changeset to my personal server then pull it down at home. After I pull it I will rebase my temporary commit on top of any commits that I have pulled down from our true publishing server.
Any way to avoid the auto-moving of a pulled changeset to public would be great. This remote repository is a complete and total draft server for myself. Being forced to manually move the changesets back to draft after an unsuccessful rebase attempt is really starting to wear on the nerves.
References
https://www.mercurial-scm.org/wiki/Phases
Introduction to Mercurial Phases
How do I tell (locally) mercurial that a server is non-publishing?
After pushing to a review repository, "abort: can't rebase immutable changeset" on rebase
That seems like a bug. What version of Mercurial are you using? Have you tried filing a bug at https://bz.mercurial-scm.org ?
I got this resolved through help on Bugzilla. Here is a snippet of my final post there (thanks for putting me on the right track djc).
It looks like we can chalk it up to User Error/Bad Test Cases (of
course). If there is anyone to blame (besides myself) it could be
TortoiseHg. My test cases consisted of stripping commits and from one
of the two repositories and then changing the phase of that commit in
the other repository and push/pull again. It seems like TortoiseHg
would pull in the wrong phase sometimes (possibly a caching issue). I
can still reproduce this when I switch my server back and forth
between publishing and non-publishing (but not quite as consistently
before).
However, doing a command line pull seems to get it working every time.
I was using command line to check outgoing/incoming, do the phase
changes and such, but possibly never used it for the actual pull.
Sorry to waste everybody's time. I resolved it as invalid, not sure if
someone wants to change it to a better category. Let me know if there
is anything else you want me to check or expand upon.
I'll edit in any updates, let me know if anyone is still having trouble with this.
I use Mercurial in a single-user workflow to have the option to roll back changes if my coding or writing goes horribly wrong (I primarily use the Stata and R statistics packages and LaTeX). While working only locally, this has been easy since all I have is the main repo.
Recently I have started ssh-ing into a Linux server for more computational power. So far I have been manually copying files back and forth and using Mercurial only locally, but I would like to use Mercurial to take care of this and keep these two workflows synchronized. Also, I like the ability to code both locally (on my laptop or desktop) and on the server.
Do I need to work on a clone of the main repo on the server and keep the main repo untouched? Or can I work directly in the main repo when I am on the server? In this question #gizmo points to this workflow guide; the "single developer" discussion is helpful, but it's still not clear to me that I can work in the main repo while I'm on the server without causing some major problem that I don't yet understand.
Thanks!
Edit: I should add that I have worked through Joel Spolsky's HgInit.com tutorial and I'm comfortable pushing/pulling/cloning/etc over ssh, but I am still not sure if I can work in the main repo without causing heartache later. Or maybe this is more a philosophical question? Thanks!
Mercurial is DVCS, it means - in each location you have both: local working copy and local repository
Mercurial is DVCS, it means - you can freely exchange (pull|push) data between repos (if they provide remote-access methods).
If you
comfortable pushing/pulling/cloning/etc over ssh
and don't forget perform pull|push cycle around your work at home (in order to don't run hg serve at home-host and sync from server as source) you don't get any headache at all with perfect linear aggregated history on each place. And even you forget to sync repo sometimes, you get in worst case two heads later, which you'll be able to merge easy (doesn't know formats of Stata and R data-files, but LaTeX, as text, is mergeable)
There is no problem with working directly in the repository on your server. From Mercurial's point of view, the "main" repository is just another random repository — Mercurial doesn't consider it to be special.
You don't say this directly, but one thing that people ask is "What happens when I push to the server?" The answer is that hg push only sends data into the repository (the .hg/ folder). The working copy is not touched on the server when you push to it. Since you push new changesets to the server, you might need to run hg update the next time you work on the server. This is just like if you had run hg pull on the server — there you'll also merge or update afterwards.
I have this situation all the time: I create a repository at home and clone it to my computer at work. I change files in either location and push/pull between the two repositories. If I need to share my work with others, then I make a repository at Bitbucket and push the code there. That way Bitbucket serves as a nice canonical repository for the code and I typically change the default path to Bitbucket in the repositories at home and at work. So at home I would have:
[paths]
default = httsp://bitbucket.org/mg/<repo>/
work = ssh://mg#work/<repo>
so that I can do hg push to send things to Bitbucket and hg pull work to grab things directly from work (in case I forgot to push to Bitbucket before leaving).
We are just beginning to learn and evaluate Mercurial, due to an increasing number of nightmare merges, and various other problems we've had with SVN lately.
A client wants us to pull down a live copy of their site, do some SEO work on it, and push it back to them. They have no source control at all. I figure this is a great project to work on with Mercurial. Instead of putting it into our SVN and exporting when we are done, we'll use Mercurial... But right away it seems I have some problem :)
They have a file called ---.config which seems to cause our Mercurial to barf. It just can't commit that file. I've created the repo and committed everything else, but I just can't get this one file committed.
We are running on Windows 2008 x64 with TortoiseHG 1.0.
I suppose I could ignore the file since it is unlikely we'll need to work with it, but still - I'd like to learn how to use Mercurial a bit better. Is there a way around this?
EDIT: here is the error message:
('commit', GetoptError('option ---.config not recognized', '-.config'))
This happens when I hit the "commit" button in TortoiseHG with that file selected.
Not sure about hg, but most command line tools treat anything after a -- as a non-option. This is helpful if you have a filename that starts with -- or a wildcard that picks up such a file; try prefixing your filename or wildcard with --, e.g., hg command -- *.config.
The problem is that TortoiseHg did not escape filenames correctly when calling hg. When a filename starts with --, one must take extra care when using it on command lines.
I have just sent a patch which will hopefully make it into TortoiseHg 1.0.1, which is scheduled to be released later today.
I am new to the dvcs world. My company uses perforce and I'm not a fan so I thought I'd try to use mercurial as a front end. I set it up on a windows machine with TortiseHG, enabled the Perfarce extension, did a small checkout (limiting the target revision) and pulled for the rest. This seemed to be more robust than clone alone.
This seems to be working fairly well as I've been able to get up to change 8700 or so.
My problem is with an error in the perforce repo. During the hg pull command it hits an error abort: file path/to/file.pl missing in p4 workspace and rolls back the transaction.
Is there anyway to bypass or skip that file and force it to continue since this is not a file I care about.
Update:
According to the admin, the file in question was a symlink. Would that cause this kind of problem? If so, how do I/admin fix or bypass it?
Is it possible to check out just a part of a perforce repo rather than the whole thing?
The issue is with symlinks that are not supported out on Windows.
This is fixed in the current version of Perfarce, which should appear in TortoiseHG soon.
I suggest that you have someone check that the Perforce repository is actually in a sane state. There might be something broken which you triggered and the data of your company might be at stake, so someone should definitely look what is causing the problem.