My scenario:
A set of shared repositories needs to be locked for a given time so a process can run for a given time. After this process is done, I want to unlock the repositories. It's a process not on the repositories, but on a different system.
The repositories are not what the process is working on. I just need a time frame where the repositories are "protected". I just need to make sure the repositories don't change while this process is running.
I want a simple way to lock a repository, so no one can push to it.
If I manually create a .hg/store/lock file with a dummy content, do you see any problem with it?
Initial testing shows it works, but I'm concerned that I might not be aware of the implications.
If you just need to generally deny access to the repos for a given period, then you can do it that way. There shouldn't be any side-effects or other consequences.
Clone the repository and then run your process against the cloned repo.
Related
Recently I have rewrote a lot of history (Forgive me Father, for I have sinned). Our old repository had a lot of sensitive information as well as unnecessary merges (up to 20 anonymous branches running simultaneously and being merged back indiscriminately), so I have striped several commits, pruned dead branches, rebased / squashed commits, rolled back unnecessary merges, created bookmarks, etc.
We now have a clean repo. I have also run unitary tests along several revisions to make sure that I haven't broke anything import. Yesterday I've forked the old repo (for backup purposes) and pushed the clean repository upstream. We are a small team and synchronizing changes was not a problem, every developer in my team is already working with the new repo.
Anyway, my local repository now have a .hg/strip-backup folder of around 2 Gigabytes.
From what I was able to understand, this folder contains backup bundles for every one of the destructive commands that I have run. I no longer need those.
My question is: Is it safe to remove the bundles inside .hg/strip-backup? Or will I corrupt my local repository if I delete those files?
Bonus question: Is there a built-in mercurial command to remove backups or should I just use rm .hg/strip-backup/*?
Yes, it is safe to remove the whole folder. The information contained in the folder is not relevant to the repo.
As a bonus answer, your best option to clean-up the cache folders is to simply re-clone the repo. Doing so allows you to start fresh and all the temporary files will be left on the base repo. Replace the original repo with a cloned repo and you won't have to bother with this history of temporary files for a while.
I was wondering what ways are are there to sync web projects initialized with git and mysql databases between 2 computers without using a 3rd one as a "server".
I already know that I could use a service like Dropbox and sync data with it, but I don't what to do it so.
If the two servers aren't always available (in particular not available at the same time), then you need an external third-party source for your synchronization.
One solution for git repo is to use git bundle which allows to create a kind of "bare repo" in one file.
Having only one file to move around make it any sync operation easier to do.
You will have to copy a bundle from one server to another (by whatever mean you want), in order for the second repo (on the second server) to pull from (you can pull from a git bundle: it acts as a bare repo) that bundle.
Just clone from one to the other. In git, there is no real difference between server repos and local repos in terms of pulling and cloning. Pushing from one to the other is tricky if neither is created as bare. Generally in that case, rather than push one from the other, we'll pull back and forth as needed.
I've set up a job in Jenkins that polls my Mercurial repository, using the Mercurial plugin. This works well once I push to the repository. I can trigger a build of the job manually, but I can't trigger the hg pull/update that happens as part of the poll, which means I have to wait up to 60 seconds for the build to start with my new changes. Sometimes I'm pushing changes that I know will affect and possibly break the system build and want faster feedback. What's the best way to pull/update before a manual build?
Is your quiet period set? You can change that to 0 to trigger builde immediately (http://jenkins-ci.org/content/quiet-period-feature)
Also, you could have two jobs, one that you have right now, and a second one that only polls for changes. The "poller" could trigger your current job when it sees changes ("Build after project").
I would suggest if your having issues with update/pull with hg. what you can do is is the use the execute shell to update your build since your shooting off your build manaually. Then you can have the job build periodically; so it will cause your pull to happen whatever you set you build period to be. You wont have to worry about polling your SCM.
It seems that I am wrong. I must have missed something in the log when I was initially testing this, or maybe I hit the manual build link before the push went through to the server. Jenkins seems to perform a hg incoming then hg unbundle then hg update at the start of each build, even when the build is triggered manually, which is exactly what I wanted.
I want to keep Mercurial servers at four different locations, and want them to be identical at any given time. Meaning, any change to any of them must be propagated to all other servers. How to do that?
You can add an action on the server with an incoming hook.
Hooks allow you to automate tasks when events happen on the repository. Whenever you get a push into the repository, you can push to your mirrors as well.
More on hooks: http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html
If I want to set up a smallish Mercurial repository for some internal work among a few developers, can I just navigate to a network share and create a repository there, and then just clone that down locally? Or do I need to set up a server (I know, it's easy to do).
This is Windows by the way.
Specifically, I'm wondering if there will be concurrency issues, like abandoned transactions, etc. if multiple users work push/pull simultaneously.
So long as folks are interacting with the repo using only 'clone', 'push', and 'pull', you're in fine shape. What you can't do is have multiple people committing directly from a shared working directory. However, push, pull, and clone are safe to use to a shared folder from a user's personal repository. All changes end up effectively atomic, and no aborted work should cause anyone any problems.
When creating that clone consider using clone -U so it's created without a working directory so folks aren't tempted to edit and commit there.
There's no reason I can think of why you wouldn't be able to do so. I do something similar, only I don't use CIFS, but ssh to access the files. No server setup to speak of in either case.
The only thing that came to mind as a possible problem was concurrent access, but you can see for yourself that Mercurial takes care not to allow users to step on each other's toes.