Is there any option or extension/tool to inform you if someone else has pushed changes to a central mercurial server? I often find that someone has pushed changes for a bug fix but I don't know until I manually check and that's getting old really fast.
You could configure the notify extension on the central server to send out an email when changesets are pushed to it. If you're looking for a client-side solution and you are using Windows, you could try HgAssist.
Related
In Mercurial, is there a way to find out if I'm authorized to push changes to a remote repository (without actually doing a hg push)? I simply want to verify that the settings in hgrc on the local and remote server is correct.
The only way to be really sure is to try it—and even then, if it succeeds, that just means you had permission; maybe you don't now.
That said, you can simply push to them a commit that you got from them, to see if you have all the permissions required to get that far. You will end up sending them nothing and writing nothing, but you'll test as much of that code path as you can test without actually sending them something.
So here's the sitch:
I am working on a Unity game project with a few others. We are using Tortoise with a repo hosted on BitBucket. One of the other people pushed a version with a huge amount of unnecessary files that we had previously deleted. I'd like to revert his push if possible. Ideally, without having to pull what he has pushed because I don't want to spend 20 mins downloading all of these extra files just to get rid of them again.
Is there any way to do this? Is it possible to push my current commit as a fresh copy to the repository?
Thanks in advance for any help
Actually, if the files were previously in your project and then deleted, they will be in your local copy of the repo already. The repo includes all the history for your project. You could see them if you did an "hg update" to a past version which included those files.
That said, to revert the change use BitBucket's web interface:
How do I delete/remove a push from Bitbucket?
A coworker got this error after pulling from the repo. I searched for an answer online on how to solve it but couldn't find anything. I figured out a way to solve it so posting it below for anyone else with the same issue.
I asked everyone else working on the repository to check their user cache folder (C:\Users\username\AppData\Local\largefiles on Windows) to see if they had a file with that id ("XXX" from the title).
One of them did, the original author of the file.
I asked him to send it to me, I remote connected to the server that has the central repo. I then copied the file both to the server's cache and into .hg\largefiles
The user could then pull again and push and everything worked.
LF extension seems not compatible with keyword extension.
With these both extensions, at the commit, the LF is NOT put in the configured folder on the PC and then raises this error at push.
If you disable the keyword extension, it's perfectly working.
Unfortunately, I've not found any additional explanations.
If someone could provide a stable solution, it will be great.
It looks like hg pull is happily sparse, but hg push is not; thus you need all largefiles for every revision not already present on the new remote, so that it can populate for history and allow clients to successfully pull at any revision. Which makes sense.
When migrating to a new hg server, I hit this issue. The "within Mercurial" solution was to download all largefiles, for all commits, to my local repo, and then push to the new server repo:
$ hg lfpull --rev 1-tip
$ hg push newbox
(Disclaimer: my Mercurial-fu is weak, I only use it for this one largefile repo)
I have a problem when I'm pushing my code and files to the remote server.
It says that the changes (after they were commited) were pushed successfully onto the remote server but the changes are not visible on the server.
Since I don't have access to the server, how would I go about debugging this problem to find out where the problem occurred (the logs on the server don't show anything I am told)?
Maybe important note:
I had to force push the changes because it wouldn't sent them otherwise.
Second question:
How can I re-push my changes?
If
$ hg outgoing
shows nothing, then the changes are already there on the server — I promise! If you had access to the server, then running
$ hg log
would reveal that the changesets are really there. The confusion must be that the working copy on the server is not updated when you push changes to it. So someone needs to run
$ hg update
on the repository on the server to actually make the working copy update. Normally, you don't need a working copy on the server, but if you're using Mercurial to publish, say, a website, then you'll want a push to also update the working copy.
The solution is to add
[hooks]
changegroup = hg update
to the .hg/hgrc file on the server. Maybe you can ask some admin to install that hook for you?
I'm trying to find out Mercurial advantages and i've read something about commiting between developers without influence on main branch.
I know i have to commit to my local repo, and then what? I don't like to push it to server (then everyone will see it right?), but just to one concrete user. I'd like him to fix something for me and send me back his changeset. Then later I'll push everything to server.
How can i do that? How should i do that in mercurial?
Run hg serve on your system. It will print something like:
listening at http://yoursystem.someplace.com:8000/ (bound to *:8000)
Assuming the other developer also has a clone of the server project, he can run:
hg pull http://yoursystem.someplace.com:8000
to get your updates.
Later you can reverse the process to get his changes back to you.
Hg serve is the easiest way, but if firewalls prevent you from doing that you can create a bundle and send it by email:
hg bundle thebundlefiletocreate.bundle http://URL/of/your/central/repo
then you can email the resulting thebundlefiletocreate.bundle file to the person. They can apply it with:
hg unbundle `thebundlefiletocreate.bundle`
This is a pretty clumsy way to work though. Using hg serve back and forth (as Mark suggested) is better if possible. Ideally you create a repo you can both read/write on a shared server or drive and both push/pull to it.