I am planning to move the central repo, I want to display an error message to anyone that is trying to use: hg pull and tell them the new location of the repo. I wrote a hook that uses events, but none of the events are triggering if someone uses: hg pull
pulling over HTTP
any ideas??
ssg's answer is extremely easy and here is one more easy way based on preoutgoing hook. You need to put this in your .hg/hgrc of your remote repository.
[hooks]
preoutgoing = echo "Repository moved to <url>"
Related
We have a project that lives in a mercurial repository.
Our customer would like to take ownership of the code base by doing the following:
Set up a mercurial repository on a server belonging to the customer.
Import the existing code into the new mercurial repository.
What is the best way to achieve step 2?
Is it a simple matter of doing the following:
Clone the existing mercurial repository:
hg clone <existing mercurial repo URL>
Push the cloned repository into the new one:
hg push <new mercurial repo URL>
Am I missing any steps? What about the hgrc file? Does it have to be modified in any way prior to pushing the project into a new repository?
Yes, you can do what you state, however it is worth noting that if you do a simple hg clone of your main repository, then a link will exist between the two, which may not be what you want. You can remove this link by editing the .hg/hgrc file and removing the default = ... item in the [paths] section.
I find that a better way is to do it without cloning. This way you don't have the link between repositories, which as this is going to a customer may be what you want.
The basic method is to set up a new repository with no changesets, and then bring in all of the changesets in one of three ways:
Push the changes from your repository to the new repository.
Pull the changes from into the new repository from the old.
If you don't have access to the new repository, create a bundle that can be provided to the customer - this can then be unbundled or pulled into the empty repo.
Pushing and Pulling is done as you normally would, but specifying the repository location:
// create the empty repository
hg init .
// pull in everything from the old repo
hg pull /projects/myOriginalRepo
or to push...
// create the empty repository
hg init /projects/myNewRepo
cd /projects/myOriginalRepo
hg push /projects/myNewRepo
Creating a bundle is perhaps a nicer way, as you can write the bundle onto a DVD and give it to your customer wrapped in a bow with a nice greeting card:
cd /projects/myOriginalRepo
hg bundle --all ../repo.bundle
Everything gets written out to a single file, which can then be extracted with hg unbundle repo.bundle or hg pull repo.bundle, into a repository with no existing changesets.
Regarding the hgrc file, as already mentioned in another answer it is not a controlled file, and so won't be copied. However, any contents are likely things like hooks to perform auto-building, or validating changesets before they are applied. This is logic which would probably only make sense to your own organisation, and I would suggest you wouldn't want this to be imposed on your customer - they are, after all, taking ownership of your code-base, and may have their own systems in place for things like this.
In the simple case - it's all.
But if you have modified .hg/hgrc file then you need to move it to the remote server manually and (if necessary) modify it correspondingly to a new environment.
Ie: you could have hooks set up in the original repository.
As of clients - just change a path to a repository in a default section (or any other section if you have several specified)
To move the master repository, you need to (a) create the new master repo and (b) tell the existing clients about it.
Create the new master repo any way you want: cloning or init+pushing, it makes little difference. Be sure to move any contents of the old repo that are not under version control, including .hgrc and any unversioned or ignored files that are not discardable. If you cloned, edit the new master's .hgrc and remove the default path, so that it doesn't try to talk to the old master repo any more.
Existing clones of the old master repo still push/pull from the old master. Everyone must edit their .hgrc, updating default (and/or default-push) so that it points to the new location. (They may also need to update authentication credentials, of course).
Only then is the migration complete. Remove (or move/hide) the original repo so that if someone forgot to update their repo path, they'll get an error on push/pull instead of pouring data down a memory hole.
in order to bypass the JIRA-mercurial plugin, I need to replicate my (private) mercurial repository in a private mercurial repository in bitbucket. I and the other users will continue to "push" our commits to our own private repository, but I want pushed commits to be "forwarded" to a certain bitbucket repository. This way, I can use the JIRA's bitbucket plugin and see the changes related to my bugs.
In other words, I want that, after each push in my private mercurial repository, the commits are forwarded to my repository hosted by bitbucket. I think I should create a push hook, but I never used them before...
I think that the following hook (installed on my server) solves my problem...
[hooks]
changegroup = hg push ssh://hg#bitbucket.org/path/to/my/repository
(Pls, move it into comment of Matteo answer)
changegroup isn't correct type of hook for this task, because
The changegroup hook is activated once for each push/pull/unbundle,
unlike the commit hook, which is run once for each changeset
according to docs, and I suppose, more right way is
[hooks]
commit =
Depending on what mercurial client you are using, there are a number of different ways to have your local repository "push after commit".
The TortoiseHg windows client allows you to configure this per-repository for all commits (under the "settings->commit" dialog), as well as for individual commits under the "options" menu when committing.
There are also hook scripts that you can use. A quick google search finds many different options.
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.
I have a project that I want to push to a Mercurial repository on Google Code.
I initialized a Mercurial project locally and checked in the code locally.
The only instructions I can find on the Google Code repository are for cloning:
hg clone https://blahblah.googlecode.com/hg/ blahblah
But I assumed that pushing should be similar.
So I tried:
hg push https://blahblah.googlecode.com/hg/ blahblah
But I got an error saying "invalid arguments".
One of the options it provides is "force push". Is this what I need?
If you are trying to push back a repository that you cloned, try
hg push
otherwise try
hg push https://blahblah.googlecode.com/hg/
For future reference, here's the usage information from Mercurial's built-in help system:
$ hg help clone
hg clone [OPTION]... SOURCE [DEST]
$ hg help push
hg push [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]
I think the reason hg push is failing is because you're giving it too many arguments.
Try the 'force'. Force says "and you're allowed to create new remote heads". You google code has no changesets, so no heads, so you're going from zero to one. I still wouldn't expect that 'force' is required, but it's definitely worth the try.
Most people starting a repo from scratch would have cloned the empty repo from google (or bitbucket) first, and then made their changes, and then pushed. I think this is what las3rjock thought you did.
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.