i have this in my .hgrc but the extensions are not working
any idea why? im on a mac.
perhaps i could point it to their path? but I can't see to find anywhere where that would be.
thank you
.hgrc
[extensions]
fetch=
hgext.extdiff =
You haven't configured extdiff, so it won't know what to do. and you need to specify hgext.fetch = instead of just fetch =
Related
I am using Merucrial with the pager extension, and I am trying to configure out to use the pager for blame, but it's not working.
I have in my .hgrc file:
[extensions]
pager =
[pager]
pager = less -FRX
attend = diff, status, help, log, blame
The other commands - diff, status, help, and log are correctly routed through the pager, but blame is not. Any ideas as to why?
blame is an alias for annotate. If you specify annotate rather than blame in the .hgrc, it works fine.
I guess the pager.attend attribute does not accept aliases, it needs the name of the original command.
I filed a bug for this.
I am setting up a central mercurial server, and want to host multiple repositories. Every web page I look at about this says to set up a config file that looks like this:
[collections]
repos/ = repos/
Where /repos is the folder and /repos is the path to use in the URL.
My question is which /repos is which??? I may want to use a name that is not the same as the path, as in:
[collections]
A/ = B/
Is A the physical path or the url path? Such a simple question you would think would have been answered, but I could not find any nontrivial examples.
Ok, I got it. This is on Windows, and here is everything that I need in the hg.conf file:
[paths]
foo = C:\Data\repositories-hg/foo-hg
bar = C:\Data\repositories-hg/bar-hg
This lets met access the repo at the location C:\Data\repositories-hg/foo-hg as:
http://server:8000/foo
Therefore A is the url alias and B is the physical path. There's of course more to set up, but this accomplishes what need for now.
I have used mercurial's bfiles extension for some time and it works fine. The only problems are installation and the special "hg bfadd" command.
Now that Mercurial 2.0 include the largefile extension I would like to switch.
Can't find any tools or guides on how to do it? Anyone tried it yet.
I have several repositories that all use the same store and have the following mercurial.ini.
[bfiles]
store=\\Someserver\Mercurial\bFilesStore
autostatus = true
autoupdate = true
autorefresh = true
autoput = *
You can find the documentation here : https://www.mercurial-scm.org/wiki/LargefilesExtension
To enable the extension add the following to your hgrc :
[extensions]
largefiles =
You can add a new large file with :
hg add --large thisfileislarge
About the migration, the readme.txt of the bfiles extension says something about a migrate.txt file ( https://bitbucket.org/gward/hg-bfiles/overview section "The future"). But I can't find the file anywhere on the repository, maybe he forgot to upload it.
There's also a mail on mercurial-devel about this : https://www.mercurial-scm.org/pipermail/mercurial-devel/2011-October/035161.html but nothing since then.
Maybe the better solution is to contact the author of bfiles about his status on the migration process and keep using the old extension until you have an answer ?
Either way, there's a lot of bug report about largefiles since the release of 2.0, so it's maybe a good idea to wait anyway :)
In the latest hg-bfiles version (from 2011-12-05), if you update to the migrate branch, you get this help file:
bfiles: migrating to largefiles
If you want to migrate from bfiles to the new largefiles extension in
Mercurial 2.0, you first have to decide: convert your repo or keep it?
Converting your repo
This is appropriate if:
you have a small repository
you know exactly where every clone of it is
you can replace every clone
It involves creating an new repo with .hgbfiles/ replaced by .hglf/.
This means that your changeset IDs will differ, so you cannot
pull/push between the old and new repos. You must replace every
existing clone with a clone of the converted repo.
The advantage of converting your repo is that you can say goodbye
forever to bfiles, and move into the future using largefiles alone.
The process is mostly automated by two shell scripts: convert-repo and
convert-store.
Use the convert-repo shell script to convert the repository itself. This is just a wrapper around "hg convert" that takes care
of all the fussy details needed to turn .hgbfiles/ into .hglf/.
It's easy to run:
./convert-repo SRC-REPO DST-REPO
The resulting DST-REPO is not yet ready to use: you still have
to convert the bfiles store to a largefiles store.
Use convert-store to turn the bfiles store into a largefiles store. You must have a local copy of the bfiles store -- so you
probably want to run this on the server where your bfiles store
lives. Again, it's easy:
./convert-store SRC-STORE DST-REPO/.hg/largefiles
Putting the store inside your DST-REPO is the easiest way to
make largefiles just work.
Keeping your repo
(Yes, that's the end of the file, there's no help on how to keep your repository)
When I create a new repository, I can ask TortoiseHG to give me a .hgignore file. Is there a way that I can customise what that file will look like, rather than having to go and get one manually from somewhere every time?
It's an old question, put still popped up as the first result on google, so here is an update:
In the TortoiseHg settings under the tab TortoiseHg users can specify the path of a Repo Skeleton. You can put your predefined .hgignore there, and it will be automatically copied during hg init.
See also:
#3569 Allow user-defined default .hgignore file when creating a new repository
TortoiseHG Docs
Like Tim already said in his comment, apparently it's not possible to do this.
Take a look at the following issue from TortoiseHG's bug tracker:
#966 Include some reasonable defaults in .hgignore on repo creation
Quotes from this link, both by Steve Borho (THG project lead):
This topic comes up on the Mercurial mailing list once a year or so and Matt always shoots it down. There is already support for user level ignore files; one could add these globs to a global file and be done with it.
and:
If a user has files or directories that they always want to ignore, they can add those to a global ignore file without having to introduce any new behaviors in THG.
So putting the things you always want ignored in a user-global ignore file seems to be the only option (even though it's not exactly what you're asking for):
Would like to create some defaults for my .hgignore files in TortoiseHG/Mercurial
(the question that I posted in my comment above)
Global hgignore usage
I have a script that is in the top level of my working copy and would like to use it as a Mercurial hook. If I use an absolute pathname to the hook then everything is fine, but I want a relative pathname so the whole thing can be easily moved around, used in other working copies and other developers can copy the hgrc as is.
/space/project/.hg/hgrc contains
[hooks]
update = genid
The genid script is at /space/project/genid
The hook is invoked just fine if I am in /space/project but if my current directory is /space/project/src/tools then 'hg update' will give an error as the hook cannot be found.
Python hooks cannot use a relative path. Script hooks can like this:
[hooks]
update = ./genid
In certain cases, environment variables are expanded in mercurial configuration. So you can check out if you can use a environment variable.
[hooks]
update = $MercurialHooks/genid
See Faq (12) in https://www.mercurial-scm.org/wiki/TipsAndTricks
I had the same problem and couldnt resolve it. The workaround was easy though! I versioned the file in the repo and just copied it to my .hg folder! Not ideal but it isnt that likely to change and other repo users can still get a copy of the file