We have an existing cc configuration that was setup by someone before I got here.
We've converted our repository from cvs to mercurial stored on bitbucket.
Everything in my question below is basically just wondering, where do I point to the bitbucket repository in my setup to check for changes? And information about my specific setup.
Looking at how the cvs projects were set up, we have a config.xml and a projectbuild.xml file that contain information about the repository.
I've found the documentation for tag options for the config.xml here :
http://cruisecontrol.sourceforge.net/main/configxml.html
but I'm not sure where I can actually look at the bitbucket repository to check for changes. I assume this would be in the projectbuild.xml file, but I'm not sure what the tag options would be for mercurial. I'm more than happy to be pointed toward some documentation, all I've been able to find is stuff on the config.xml.
Here is part of my config.xml and my projectbuild, or build-tnl-default.xml file as it's called for my specific case:
config.xml (Notice I don't have bootstrappers in this file, I've seen this in other examples and am not sure if this would help me.
<modificationset quietperiod="900">
<mercurial localworkingcopy="projects/${project.name}">
</modificationset>
<schedule interval="100">
<ant anthome="C:\usr\local\apache-ant"
antworkingdir="projects/${project.name}"
buildfile="build-tnl-default.xml"
uselogger="true"
usedebug="false"
propertyfile="C:\usr\local\ia\build.properties"/>
</schedule>
build-tnl-default.xml:
<project name="build-tnl-default"
default="build">
<target name="build">
<!-- Get the latest from mercurial -->
<mercurial>
<!-- Call the target that does everything -->
<ant antfile="build.xml" dir="tnl" target="all"/>
</target>
</project>
Here I have no idea what options are available to me in the mercurial tag. I assume I just need to point this to the repository on bitbucket? In the previous version, it looked like this was pointing to the cvs repository here. I'm just not sure what the mercurial attributes are.
I'm sorry about my newness with this stuff, I might require a little more explanation than many other users. Any help is appreciated. Thanks
You check for updates in your repository (regardless whereever it is hosted) via
<modificationset quietperiod="900">
<mercurial localworkingcopy="projects/${project.name}">
</modificationset>
These tags say, that you query the repository you've checked out under projects/${project.name} and that a build is triggered if within a time frame of 15 minutes (900 seconds) no further changes occured. (I think that 15 minutes is a bit much, btw)
Simply make sure that projects/${project.name} is a Mercurial project that was checked out via hg clone http://repositoryAtBitbucketAsAnExample projects/${project.name} (make sure to expand ${project.name}).
I did not fully understand what build-tnl-default.xml is supposed to do, but if it should grab the newest build.xml, you should think about doing it with an Execootstrapper running something like hg pull ${path.to}/build.xml.
I have no idea what options are available to me in the mercurial tag.
You should determine the <taskdef .../> is used that loads the mercurial tag. This should be somewhere in build-tnl-default.xml or a file that is imported by it.
Related
I am in the process of rebuilding a API documentation site for an open source project where we want to keep an archive of previous releases. I am wondering how I can configure Jekyll to generate the right hierarchy?
We have the following directory layout in our current /docs folder (which we would like to reuse in Jekyll somehow):
current/
v1/
v2/
v3/
Whenever we release a new version the current folder gets copied to a new folder (say v4). The contents of each folder is something like this:
introduction.md
testing.md
api-foo.md
api-bar.md
I'd like these to be available under the url domain.com/v3/testing/, domain.com/current/testing/, etc. I see that I could probably employ collections to do this, having one collection per version. To do this I see myself auto-updating the _config.yml as part of a build script (I made an example doing this here), but I am not sure how to progress from here, or if using collections for this is the wrong approach ...
This is too brief of an update to be of real quality, but thought I would mention that we solved this in the end in the Sinon project. Check out the repo at GitHub sinonjs/sinon and see the docs folder as well as the scripts called from package.json.
Feel free to improve on this answer by editing it and adding content and links.
I'm a complete noob at Mercurial API and Python, but I'm trying to write a useful extension for myself and my colleagues now.
Let's assume I have a repository which contains some code and an auxiliary file .hgdata. The code and .hgdata are both under Mercurial's control. When I execute a command pull-extended which is provided by my extension, I want it to make a pull and then to analyze the state of a .hgdata and probably make some additional actions. The problem is that when my command is invoked, it just pulls the incoming changesets, but it can't look into the actual .hgdata without making a preceding repository update. Is there any way to watch the after update .hgdata besides repository update?
I've received an answer on the Mercurial's official IRC channel:
In order to get an actual file state after making a pull, we may use repo[revision][file].data().
P.S. I haven't checked that yet. If it works, I will close the question.
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)
We use tortoise hg with Kiln. In my vs 2010 c# project there are some files that are part of the repository but I would like tortoise hg to ignore them when I make a commit.
For eg., say in a login screen I may hard code the userid, password for testing. I dont really want this file considered during a commit. I understand .hgignore file but this really works for files that are not part of the repo. Any trick in tortoise hg to ignore files that are part of the repo ? (so they do not show up as modified (M) during a commit.) thanks
I always use a combination of .hgignore and BeforeBuild (in the .csproj file) for things like this.
In one of my pet projects, I have the following setup:
App.config contains my real hardcoded user id and password for testing.
App.config.example is identical, but with fake data like "dummy_user" and "dummy_pw".
App.config is not part of the repository, and it's ignored (in .hgignore).
App.config.example is part of the repository.
Then, I have the following in the BeforeBuild target in the .csproj file of my solution:
<Target Name="BeforeBuild">
<Copy
Condition="!Exists('App.config')"
SourceFiles="App.config.example"
DestinationFiles="App.config"/>
</Target>
All this together has the following effect:
the config file with the real data can never be accidentally committed to the repository, because it's ignored
the repository only contains the config file with the example data
if someone else clones the repository to his machine, he won't have the "real" config file...but if it's missing, it will be automatically created before the first build by Visual Studio / MSBuild by simply copying the .example file (and then he can just put his real login data into the newly created App.config file).
if an App.config with real hardcoded user data already exists, it won't be overwritten when building because the BeforeBuild event will only happen if App.config does not already exist
The answer by Christian is the right one, but I want to mention that TortoiseHg supports what you want with their Auto Exclude List.
One problem with an exclude list is that it cannot work with merges: you must commit all files when you merge and so you'll have to do a little dance with shelve, merge, commit, and unshelve.
When you do a TortoiseHG commit, there is a list of files with checkboxes by them. Deselect the files you do not want comitted.
Or, on the command line, do a commit of the form hg commit --exclude "pattern", where pattern is defined in the hg man page.
You could always use hg forget.
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