I have a centralized Mercurial repository which I want to provide access to via SSH.
I did a chown root:developers repository -R on the repository directory, so all users in group 'developers' should have access.
So, I clone, add my initial files to the repository as user A, commit, push, done. Now, I go as user B, clone, add a file, commit, and push. But then, when I do a pull, an update, and change that file as user A and then try to push, I get
pushing to /var/hg/repository
searching for changes
1 changesets found
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: Permission denied: /var/hg/repository/.hg/store/data/test.i
Am I missing a configuration step? Should I not be using SSH?
EDIT I found that using the sticky bit solves the problem: How to set permissions so two users can work on the same hg repository?. Is this a bad solution?
Sticky group bit is the right way to do this. Also, it used to be the case that user's umasks needed to be set such that group read/write would be on for new files they add, but for the last year or two mercurial copies the permissions (not ownership) of the .hg directory in the repo itself on to newly created files, so the umask isn't as important.
Maybe you could be interested by mercurial-server: http://www.lshift.net/mercurial-server.html
mercurial-server is useful if you don't want to provide a shell to developers on server hosting mercurial central repository.
The Mercurial documentation says using the setgid flag is okay.
Related
I created a mercurial repository on some file servers net share.
Is it possible to automatically get the remote repository updated to tip if somebody pushes its changes?
Because some other people (purely users) may copy the repositories content (rather than cloning, because of lack of .hg) and i want them to get the newest version.
Since it is a share on a simple NAS it would be good if the pushing client could invoke this update.
It seems that a hook on the changegroup event can solve this.
Add the following lines to the repository's configuration file (repo/.hg/hgrc)
[hooks]
changegroup = hg update
This solution was suggested on a slightly different question:
Cloning mercurial repo to the remote host
At least under windows this seems only to work on local repositories. The reason for this is, that hg tries run a cmd on the remote path that fails, since it does not support UNC paths as current direcory.
Adding explicitly the repository url fixes this, but its not client independent anymore.
[hooks]
changegroup = hg update -R %HG_URL%
You could treat the server repository as your "local working directory" and then PULL from your own PC to that location. If you use hg pull --update then it will automatically update the working folder to the latest.
One way to do this is to login to your NAS and physically run the hg command line program there. If not, you could also mount the NAS folder on your local PC and then chdir to its mapped local folder and use your local hg client to do so.
This might seem like an odd thing to do but Mercurial doesn't care which is the "clone" and which is the "server", you can swap them interchangeably in your workflow.
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.
I use Mercurial on desktops, and then push local repositories to a centralized server. I noticed that this remote server does not hold local copies of files in its repositories (the directory is empty, except obviously for the .hg one).
What is the preferred way to populate these directories with local copies? (which in turn are used by various unrelated services on that server).
What I came up so far is to use a hook and hg archive to create a local copy. This would be a satisfactory solution but I need to configure a per-repository hgrc file (which is tedious but I did not find a way to centralize this in /etc/mercurial/hgrc). Maybe a global script (in /etc/mercurial/hgrc, run for each changegroup event)? (in that case how can I get the repository name to use in a if...then scenario?)
If you can get access to the remote repository, you could install a hook for when changegroups come in, and perform an hg update when that happens.
A quick check shows this in the FAQ (question 4.21), but to summarize/duplicate: edit the .hg/hgrc file on the remote repository, and add the following lines:
[hooks]
changegroup = hg update
Whenever the remote repository gets pushed to (or when it performs a pull), it will update to the latest changeset.
Some caveats - this may fail if any changes have been made to the files on the remote side (you could use hg update -C instead). Also, if you have pushed any anonymous branches (which you would have to consciously force), you may not update to what you want to update to.
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.
I have directory named "Proyectos" with Django code inside.
I need to commit the project to Source Forge so my teacher can "download" all the code to his computer.
I think I should use some of these address:
http://phone-apps-djan.hg.sourceforge.net:8000/hgroot/phone-apps-djan/phone-apps-djan (read-only)
ssh://lucasab#phone-apps-djan.hg.sourceforge.net/hgroot/phone-apps-djan/phone-apps-djan (read/write)
I did this on Kubuntu:
lucas#lucas-Satellite-L305:~/Desarrollo/Python/Django/Proyectos$ hg clone http://phone-apps-djan.hg.sourceforge.net:8000/hgroot/phone-apps-djan/django-mercurial
but only the folder is created.
I'm a novice and didn't find how to do this. I followed some tutorials but I can't understand a lot of concepts.
I would appreciate some assistance with this, please.
Thanks in advance.
You have two different address to access your Mercurial repository on sourceforge :
http://phone-apps-djan.hg.sourceforge.net:8000/hgroot/phone-apps-djan/phone-apps-djan (read-only), like said after the address, this one is read-only, it is for everyone to clone your project, so they can see the sources and compile / use it. There's no authentication. When you use this address, Mercurial use the HTTP protocol to pull the changes.
ssh://lucasab#phone-apps-djan.hg.sourceforge.net/hgroot/phone-apps-djan/phone-apps-djan (read/write), you can write to your repository through this address, but you have to authenticate yourself (you'll have to enter your password) and Mercurial use the SSH protocol to do that. You can also see your sourceforge username in the address.
First of all, you must do another clone of your project with the second address, otherwise you won't be able to commit. Just cd in a new directory and do :
hg clone ssh://lucasab#phone-apps-djan.hg.sourceforge.net/hgroot/phone-apps-djan/phone-apps-djan
You should be prompted for your sourceforge account password.
Then, you can cd in the newly created directory, do all your changes, add files, etc. When you're done, you can do a hg commitand then a hg push to publish the modification to your repository. If you add new file to the directory don't forget to do a hg add or hg addremove.
You can find a really good and simple tutorial about mercurial on Hg Init, you should read it and try to understand the workflow before doing anything on sourceforge.
Good luck with your project :)
Many thanks to Rob Sobers and Krtek for their answers. I finally could add all my files to SourceForge. I followed their instructions and everything went fine, although I had some minor complications.
This is the answer to my questions step by step:
Over the folder "Proyectos" I did:
hg clone ssh://lucasab#phone-apps-djan.hg.sourceforge.net/hgroot/phone-apps-djan/phone-apps-djan and entered the password for my SourceForge account. A folder "phone-apps-djan" was created.
hg add after I cd into phone-apps-djan and copied all the files of my project into that folder.
hg commit. There was an error at this point: abort: no username supplied (see "hg help config"). So I created a file named .hgrc in my home dir and added these lines:
[ui]
username = my username at sourceforce <the mail address I supplied when registering>
verbose = True
Then I re-entered hg commit.
hg push. The follow error message was displayed: abort: repository default-push not found!. Then I just re-edited the .hgrc file created on the last step and added:
[paths]
default = ssh://lucasab#phone-apps-djan.hg.sourceforge.net/hgroot/phone-apps-djan/phone-apps-dja
I really don't understand what happened here because the .hg directory in my repo already contains a hgrc file with that path :(. Anyway, I did hg push again.
And that was all.
Doing hg clone downloaded the repository to your computer. Now, to update your working directory (so you can work with the files), type hg update.
When you're done making changes, type hg commit to record them. When you're ready upload your changes to SourceForge, type hg push http://path/to/repo. Make sure you push up to the correct repository!