I am using bitbucket to host my main repository (using mercurial).I want to create an [incoming] hook but i cant find the .hg/hgrc file on bitbucket.I tried to create it but it won't accept it ( path contains illegal component ).
You're not allowed to run arbitrary code on bitbucket so an "incoming hook" like that is not possible.
You are, however, allowed to set up webhooks, which means that bitbucket will talk to a server you set up whenever a push, or something else, happens.
To set up a webhook, do the following:
Navigate to your repository on the bitbucket.org website.
Open up the settings for your repository
Under "Integrations" (middle of the list), there is a section for "Webhooks".
Create a new webhook on this page
Related
I want to push a repository from my computer to a repository on a remote site for the purpose of synchronizing the files. TortoiseHg seems to correctly identify outgoing changesets, but when I try to push the changes, TortoiseHg responds with "abort: destination does not support push" with "Push to https://myid:ps#mydomain.com aborted, ret 255" in the status bar at the bottom. The log file includes "(falling back to static-http)"
I've googled but I'm getting nowhere. What does "abort: destination does not support push" mean in English? What doesn't support push? What is the "destination"? Is it the settings in the config files in the repo that make it so the destination doesn't support push? Is it the way the server is set up?
One of the responses to 27967022 "Your destination does not support push, or push is disabled" So how does one enable push?
If you use hgweb on the server side, to allow pushing to a repository, add
[web]
allow_push = *
to its .hg/hgrc on the server or in your hgweb.config. You can also allow pushing only for specific users by listing them instead of *. This is documented here.
If that is not the case and you just use the https server to serve the repo as files, you'll not be able to push via https. In that case, your most likely option is to push via ssh, as in
hg push ssh://myid#mydomain.com/path/to/repo
This requires that you have ssh access to the server and that the repository lies in $HOME/path/to/repo. For an absolute path (if the repository lies in /path/to/repo and not below $HOME), push to ssh://myid#mydomain.com//path/to/repo (note the double slash).
If you always push to the same destination, you can add this path to your local .hg/hgrc:
[paths]
default-push = ssh://myid#mydomain.com/path/to/repo
so that you can then just use hg push.
What are you running for your mercurial server on mydomain.com? If it's hgweb, then #wintermute has your answer. If you're serving static HTTP (using Apache, nginx, etc.) then your server is setup for clone or pull, but not push. More likely you just need to enable push like #wintermute is saying.
I've setup a simple changegroup hook for my Mercurial repositories to email the set of changes to interested users. I'd like to use a single script for every repository I manage, and I would also like to identify the repository the changegroup came from. According to the Mercurial Hooks documentation, the environment variable HG_URL is available for this purpose. However, I am not getting what I'm expecting from this variable:
expected:
https://repo01/hg/project
actual:
remote:https::rnideffer
Why is this the URL, and how do I get what I expected into the changegroup hook?
The changegroup hook can't always tell the remote URL being used. From the Hooks chapter of the Mercurial Book:
When possible, Mercurial will tell a
hook the location of the “far side” of
an activity that transfers changeset
data between repositories. This is
provided by Mercurial in a Python
parameter named url, or an environment
variable named HG_URL. No comments
This information is not always known.
If a hook is invoked in a repository
that is being served via http or ssh,
Mercurial cannot tell where the remote
repository is, but it may know where
the client is connecting from. In such
cases, the URL will take one of the
following forms: No comments
remote:ssh:1.2.3.4—remote ssh client,
at the IP address 1.2.3.4. No comments
remote:http:1.2.3.4—remote http
client, at the IP address 1.2.3.4. If
the client is using SSL, this will be
of the form remote:https:1.2.3.4. No
comments
So you're being told they're pushing via https from a machine named rnideffer.
Have you considered using the notify extension? It ships with mercurial, does pretty much exactly what you're describing, and can be provided with the URL prefix necessary to turn repo names into the URLs you want.
I'm new mercurial user. I setup the acl extension adding this into my hgrc file:
[hooks]
pretxnchangegroup.acl = python:hgext.acl.hook
[acl]
sources = serve pull push
[acl.deny]
** = mercurial
So with this code above I deny access to all files to user "mercurial". I successfully tested the acl extension and it works perfectly when I try to push to my central repository on which I put the code above. As expected I receive message that the access for the user "mercurial" is denied.
Now the problem is when I'm start pulling from central repository I don't have any restriction so I can pull anything without any restriction. What I want is to deny pull access for some files like I can do when I tried push comand. Is there any way I can do this?
Mercurial, unlike Subversion, doesn't allow controls on individual files, and for good reason. The DVCS model puts the entire repo on every developer's machine, so even if you restrict files on push and pull, the user could still just hg cat the file to get its contents.
Instead of trying to do this on the client side, I would instead break your repos based on who needs what and set permissions to individual repos. See my answer on the Kiln stack exchange Should I use more than one repository?. You can set permissions via http(s) or SSH, or if you happen to be using Kiln, through our permissions interface.
As came out in the comments with tghw, it sounds like what you really want is partial cloning by filepath, so that a person can clone or pull down only certain files or directories, but that's not possible in Mercurial (or git). That's the case because every revision is identified by a unique hash that includes, among other things, the hash of all the file changes. If you don't have all the files, you don't have all the changes, and you can't verify the hash.
If you really need to hide read access for some files from some people you'll need to split them up into separate repositories.
I have a solution:
convert your repo to git:
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Mercurial
I have a local machine ("laptop") and a shared Mercurial repository on another machine ("server").
The shared repository is set up as a multi-repository as described in the Mercurial documentation using Apache, the hgwebdir.cgi script and Mercurial 1.4.
The setup works in the sense that I can browse the projects (repositories) in the web browser, I can clone and pull from the server, and I can push from the laptop when the project/repository already exists on the server.
But I cannot create a new project on the laptop (hg init, do stuff, hg commit) and push it to the shared multi-repository (hg push http://server/hg/my-new-project-name) - I get "abort: HTTP Error 404: Not Found", presumably because the directory/project repository does not exist yet.
How can I push a new project/directory structure to a Mercurial running elsewhere? I couldn't find anything in the documentation, how do you guys do it?
You cannot create new remote repositories over http with the built-in functionality. Your options are to either:
create with a ssh clone: `ssh clone local-repo ssh://you#remote//path/to/repo'
log in to the remote repo and do a hg init where you want the repo. After that you can push to the new empty repo
Use a cheesy http-creation CGI like the one I wrote here: http://ry4an.org/unblog/UnBlog/2009-09-17
Update
I tried using Dropbox as described below, but couldn't make it sufficiently reliable, so I'm not recommending that option.
Original answer below, kept for context.
/update
I found one more option: Skipping both http and ssh altogether and using Dropbox for shared repos.
For the one-person-multiple-computers scenario, it looks like the simplest option of the lot, and you get backups as a nice side effect.
Here is a discussion on Hacker News
I use the on-demand (hosted) version of FogBugz. I would like to start using Mercurial for source control. I would like to integrate FogBugz and a BitBucket repository.
I gave it a bit of a try but things weren't going very well.
FogBugz requires that you hook up your Mercurial client to a fogbugz.py python script. TortoiseHg doesn't seem to have the hgext directory that they refer to in instructions.
So has anyone successfully done something similar?
Post-mortem:
Bitbucket now has native fogbugz support, as well as other post-back services.
http://www.bitbucket.org/help/service-integration/
From the sounds of it you are wanting to run the hook on your local machine. The hook and directions are intended for use on the central server.
If you are the only one working in your repository or don't mind commit not showing up in FB until after you do a pull, then you can add the hook locally to your primary clone, If you are using your primary clone then you need to do something slightly different from what they say here:
http://bugs.movabletype.org/help/topics/sourcecontrol/setup/Mercurial.html
You can put your fogbugz.py anywhere you want, just add a path line to your [fogbugz] section of that repositories hgrc file:
[fogbugz]
path=C:\Program Files\TortoiseHg\scripts\fogbugz.py
Just make sure you have python installed. you may also wish to add a commit hook so that local commits to the repository also get into FB.
[hooks]
commit=python:hgext.fogbugz.hook
incoming=python:hgext.fogbugz.hook
On the Fogbugz install you will want change put the following in your for your logs url:
^REPO/log/^R2/^FILE
and the following for your diff url:
^REPO/diff/^R2/^FILE
When the hook script runs it connects to your FB install and sends it a few parameters. These parameters are stored in the DB and used to generate urls for diffs and log informaiton. The script sends the url of repo, this is in your baseurl setting in the [web] section. You want this url to be the url to your bitbucket repository. This will be used to replace ^REPO from the url templates above. The hook script also passes the revision id and the file name to FB. These will replace ^R2 and ^FILE. So in summary this is the stuff you want to add to the hgrc file in your .hg directory:
[extensions]
hgext.fogbugz=
[fogbugz]
path=C:\Program Files\TortoiseHg\scripts\fogbugz.py
host=https://<YOURACCOUNT>.fogbugz.com/
script=cvsSubmit.asp
[hooks]
commit=python:hgext.fogbugz.hook
incoming=python:hgext.fogbugz.hook
[web]
baseurl=http://www.bitbucket.org/<YOURBITBUCKETACCOUNT>/<YOURPROJECT>/
One thing to remember is that FB may get notified of a checkin before you actually push those changes to bitbucket. If this is the cause do a push and things will work.
EDIT: added section about the FB server and the summary.
Just a heads-up: Fog Creek has released Kiln which provides Mercurial hosting that's tightly integrated with FogBugz and doesn't require any configuration.
I normally wouldn't "advertise" on Stack Overflow (disclaimer: I'm one of the Kiln devs), but I feel that this directly answers the original question.
It is possible to integrate your GIT BitBucket repository with FogBugz issue tracker, but unfortunately it is not properly documented.
You have to follow steps described at https://confluence.atlassian.com/display/BITBUCKET/FogBugz+Service+Management, but beware that
In CVSSubmit URL you need to put url WITHOUT "?ixBug=bugID&sFile=file&sPrev=x&sNew=y&ixRepository=" parameters.
It should just be "https://your_repo.fogbugz.com/cvsSubmit.asp"
You will need to mention your FogBugz case ID in the git commit message
by putting "BugzID: ID" string in it (this is not documented
anywhere :-( ) similar to this:
git commit -m "This is a superb commit which solves case BugzID: 42"
Of course, commit info will be sent to FogBugz after you push your commit to BitBucket server, not after your do a local commit.