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.
Related
I'm cloning openJDK source code to my local repo, and I'd like be sure that the file integrity has been maintained in transit.
hg clone http://hg.openjdk.java.net/jdk8/jdk8/
The Mercurial FAQ says that revlogs are checked against their hashes, "But this alone is not enough to ensure that someone hasn't tampered with a repository. For that, you need cryptographic signing." Does that mean I need to use
SSH like this?
hg clone ssh://hg.openjdk.java.net/jdk8/jdk8/
And to get SSH access, do I have to sign up as a contributor to the project? If so, is there a way to get a verified clone without becoming a contributor?
SSH provides transport encryption. It ensures the data cannot be altered in-transit from the OpenJDK repository to your computer.
The Mercurial FAQ is talking about signing the commits, which ensures that you can later verify that these commits have not been tampered with individually. It means an attacker cannot break into the OpenJDK servers or falsify a commit for upstream acceptance, adding in revisions that the project doesn't mean to be there. You would be able to recognise such revisions because they lack the right signature or are not signed at all.
SSH wouldn't protect you against such issues, because SSH doesn't care about the data it transfers. Malicious (altered or added) commits are transferred just as securely as valid revisions.
Signed commits is not something you as a consumer of the repository can add later. The OpenJDK project would have to build signing into their committing procedure from the start.
Is there a tool out there (preferably web-based) which would automatically detect commits to a BitBucket repository, and at that time, copy all files in the repository to a web-server via FTP?
I basically want a quick and painless way (if one exists) to set up continuous integration between my BitBucket repository and my website.
No build/compilation step would be necessary, since these are only front-end (HTML/CSS/Javascript) files.
The changegroup hook is the way to do this. See Hooks for info about what to do with it.
I've used changegroup hooks on my own hg repositories, but not in BitBucket; it's possible that the BitBucket servers are restricted in what you can do, I'm not sure. I do know a wget/curl attempt to rebuild a manual upon my server upon updating its contents in a repository on SourceForge failed for me because they've locked up their servers too tightly (sending an email from the hook would work but not http access). I would expect BitBucket to be set up better; a quick search for "bitbucket changegroup hook" doesn't seem to indicate that there are any problems with it. Try it and see!
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
We come from a subversion background where we have a QA manager who gives commit rights to the central repository once he has verified that all QC activities have been done.
Me and a couple of colleagues are starting to use mercurial, and we want to have a shared repository that would contain our QC-ed changes. Each of the developers hg clones the repository and pushes his changes back to the shared repository. I've read the HG init tutorial and skimmed through the red bean book, but could not find how to control who is allowed to push changes to the shared repository.
How would our existing model of QA-manager controlled commits translate to a mercurial 'central' repository?
HenriW's comment asking how you are serving up the repositories is exactly the right question. How you set up authentication depends entirely on how you're serving your repo (HTTP via Apache, HTTP via hg-serve,, ssh, etc.). The transport mechanism provides the authentication and then mercurial uses that with the commands from Mr. Cat's link (useless in and of themselves) to handle access control.
Since you didn't mention how you're serving the repo, it was probably someting easy to set up (you'd have remembered to mention the hassle fo an apache or ssh setup :). So I'll ugess those two:
If you're using hg serve then you don't have authentication setup. You need to use apache, lighttp, or nginx in front of hgweb or hgwebdir to provide authentication. Until you do the allow_* and deny_* options are strictly everyone or no one.
If you're using ssh then you're already getting your authentication fromm ssh (and probably your OS), so you can use the allow_* and deny_* directives (and file system access controls if you'd like).
serverfault.com has a relevant question and links to the Publishing Repositories Mercurial Wiki page. The first shows how to configure per-repository access when using hgweb on the server. I get a feeling that you're using ssh which the wiki page labels as "private" and am therefore inclined to believe you would have to fall back to file-system access control, i.e. make all the files in the repository belong to the group "commiters", give group members write access and everyone else read/only.
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.