I have a web server which is using mercurial as the repository. Every day, we have files being written by applications to our server and I want these to be reflected in the repository. Is there a way to add an automated 'hg add' and 'hg commit' command that runs every day so these files are kept track of and can be "pulled" by our developers on their machines?
Thanks for any help!
scheduling tasks is not a job for mercurial. see crontab or Scheduled Tasks depending on your OS.
Related
I need to control the version of a few files accessible via an SMB share. These files will be modified by several people. The files themselves are directly used by a web server.
Since these are production files I wanted to force the users to pull a local copy, edit them, commit and push them back. Unfortunately there is no Mercurial server on that machine.
What would be the appropriate way to configure Mercurial on my side so that:
the versioning (.hg directory) is kept on the share
and that the files on the share are at the latest version?
I do not have access to this server (other than via the share). If I could have a mercurial server on that machine I would have used a hook to update the files in the production directory (I am saying this just to highlight what I want to achieve - this approach is not possible as I do not control that server)
Thanks!
UPDATE: I ended up using an intermediate server (which I have control over). A hook on changegroup triggers a script which i) hg update to have fresh local files ii) copies them to the SMB share
EDIT 1 Following discussions in comments with alex I have looked at the verbose version of the command line output. The \\srv\hg\test1 repo has a [hooks] section with changegroup = hg update. The output from a hg push -v gives some insights:
pushing to \\srv\hg\test1
query 1; heads
(...)
updating the branch cache
running hook changegroup: hg update
'\\srv\hg\test1'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
abort: no repository found in 'C:\Windows' (.hg not found)!
warning: changegroup hook exited with status 255
checking for updated bookmarks
listing keys for "bookmarks"
If I understand correctly the output above:
a cmd.exe was triggered on the client, even though the [hook] was on the receiving server
it tried to update the remote repo
... but failed because UNC are not supported
So alex's answer was correct - it just does not work (yet?) on MS Windows. (Alex please correct me in the comments if I am wrong)
If I understood correctly, you are looking for two things:
A repository hook that will automatically update the production repo to the latest version whenever someone pushes to it. This is simple: You're looking for the answer to this question.
If you can rely on your co-workers to always go through the pull-commit-push process, you're done. If that's not the case, you need a way to prevent people from modifying the production files in place and never committing them.
Unfortunately, I don't think you can selectively withhold write permissions to the checked-out files (but not to the repo) on an SMB share. But you could discourage direct modification by making the location of the files less obvious. Perhaps you could direct people to a second repository, configured so that everything pushed to it is immediately pushed on to the production repository. This repo need not have a checked-out version of the files at all (create it with hg clone -U, or do an hg update -r 0 afterwards), eliminating the temptation to bypass mercurial.
What prevents you from mount your Samba share and run hg init there? You don't need mercurial server (hg serve or more sophisticated things) to perform push/pull operations.
After a change in my local repo, I commit with hg commit -m <message>, then I push to my server with hg push, then in my server I update working dir with hg update.
Is there a better way to do this?
The first two steps you have described:
hg commit -m <message>
hg push
are required as per the fact that commits are kept completely separate from the server in Mercurial (and most other DVCS as well). You could write a post-commit hook to perform the push after each commit, but this is not advised because it prevents you from correcting simple mistakes during the commit and before the push.
Because you're trying to perform an update on 'the server' I'm assuming you are executing a version of the code in your repository on the server. I'm assuming this because typically the server would simply act as a master repository for you and your developers to access (and also to be subject to backups, etc..), and would not need the explicit hg update.
Assuming you are executing code on the server, you can try and replace the push and the update with this command:
hg pull <path to development repo> -u
which will perform a pull from your local repo and then an automatic update. Depending on your server configuration, it might be difficult to get the path to your local repo.
For the first part of the question (ie. automatically push when you do a commit), you can use the trick described in this answer : mercurial automatic push on every commit .
If you want to automatically update the working directory, you can do this with a hook. Add this in the hgrc of your repository (.hg/hgrc on your server directory) :
[hooks]
changegroup = hg update >&2
This will automatically update the working directory every time a push is made to this server. This hook is described in the Mercurial FAQ.
If you use these 2 solutions, the next time you do hg commit -m "message", the commit will be automatically pushed to the remote server and the working directory on the server will be updated.
There is an extension called autosync you might find useful:
This extension provides the autosync command which automatically and continuously commits working copy changes, fetches (pull, merge, commit) changes from another repository and pushes local changes back to the other repository. Think of configuration files or to-do lists as examples for things to synchronize. On a higher level the autosync command not only synchronizes repositories but working copies. A central repository (usually without a working copy) must be used as synchronization hub:
I use mercurial on a standalone computer. I have also made some small changes of the source code on this computer. Now I want to update this code with a new version that I can bring to this computer on a CD or usb-stick as a gziped tar file. How do I do this update in the best way, and keep my changes of the standalone source.
Update: I forgot to mention that the files on the USB-stick is not from a mercurial database, they are just a bunch of source-files from a perforce controlled source tree. We have mercurial only on the standalone computer.
On the remote machine (first time):
hg clone {path_to_repository} {path_on_usb_stick}
On subsequent runs:
cd {path_to_repository}
hg push {path_on_usb_stick}
Then on the local machine:
cd {path_to_repository}
hg commit
hg pull {path_on_usb_stick}
hg up
At some point, hg might warn you about multiple heads, which means there are conflicts that you need to resolve by running hg merge.
To get your changes from the local machine to the repo server, you reverse the procedure.
Why not just put Mercurial binaries and a .hg repo right on the flash drive. Then you can push/pull to/from it at home, and copy atop it at work.
Let's say the repo I have on my notebook's hard drive is cloned from a remote Repo2 initially, the "all serious" Repo, and then we use Repo1 for tmp storage and code sharing.
So now, what if I do a
hg in ssh://someuser#dev.example.com//code/repo1
and then also on repo2, and see some new changesets on both repos, how do I look at what Peter changed for the 3 files he committed and pushed on Repo1?
And how to do it for Repo2? (on Mac and PC)
What about just looking at the log history?
Is it better that Repo1 and Repo2 both run a process "hg serve" at port 8000 and 8001 for other people to look at history using a web browser?
What if there are no such processes running, then the only way is to ssh to that host and cd to the directory and do hg log and hg diff?
Yes, you must have the repository on your local machine to be able to do hg log and all other commands. Mercurial is a distributed revision control system, and so you are expected to make a local clone before you work with a repository.
Setting up hg serve is a good alternative for when you need to quickly look at the history without cloning it first. But for command line operations, you should make a clone.
I have installed mercurial and review board extension for mercurial on my Windows XP machine. In review board, I have added a repository say "MyRepo" which is on a central server.
I cloned "MyRepo" to my local machine, modified a file for testing and committed to my local repo. I haven't yet pushed it to my central repo.
Now I run "hg postreview" on my cloned local repo. I select "MyRepo" when postreview asks me to choose a repo.
I get a "File not found (207)" error after the command completion. Howver, my review request is uploaded to Review Board server but the diff file is not. Can you tell me what am I doing wrong or is there a patch or command I am not aware of?
I am a novice in DVCS and mercurial, so any help on this matter is really appreciated.
It sounds like you already pushed changes or did more than one commit to the clone (that diffs now more than one commit). Try this and refer to the changeset you created the clone from:
hg postreview -l -o --parent={changeset}
If you wan’t to submit further editings refer to the rewiewid and changeset your first postreview command submitted:
hg postreview -e {reviewid} -o --parent={changeset}