Right now I have my repo on my local drive. In order to back it up, I have to copy .hg to a window's network drive.
At
Is it a good idea to put Mercurial Repository in shared Network drive?, Lasse Karlsen said the repo shouldn't be on a shared folder on a network server because "mercurial cannot reliably hold locks in all situations".
Would this still be an issue when the repository is only updated by a single user?
If so, can someone explain to me why the corruption happens?
A while back our IT had problem setting up a mercurial server.
I am very fond of mercurial (it has a great interface and is very easy to work with), but if it's going to be such a pain in the neck to set up for multiple users, I am willing to look for something else. Does anyone have any suggestions (with reasons)?
I am looking for a revision control program that has the following attributes:
2. Good interface (allow you to easily see revision and changes to the code over multiple revisions).
3. Work as a local repo or a network repo.
4. IT will feel comfortable installing on their network.
Thanks,
Stephen
I suppose, in solo-mode (only one user|one proccess, initiated by used modify repository) repository on network drive will not lost locks and will be not broken.
But any DVCS by design offer more natural and reliable way of having backup: creating clones of original repository and syncing with upstream (hg serve + http-repo is easy way, ssh-host and ssh-type remote repo is only slightly harder way)
Here is a Mercurial list thread about "repository on Samba Share" where Matt Mackall (Mercurial developer) says "lots and lots of people do just fine with Mercurial on networked
filesystems".
That hasn't been my personal experience though. At home (single user scenario), I was running Mercurial repo over SMB on a very cheap no-name brand NAS server (implying a low quality protocol implementation) and it would reliably corrupt the repo.
I also ran a personal repo at work on a more serious enterprise NAS setup (implying a higher quality protocol implementation) and it seemed to work fine for the short time I used it (moved the repo off to a proper setup pretty quickly after the problems at home).
So I guess it depends on your confidence in the quality of the network file system provided by your IT ("problems setting up a Mercurial server" would not inspire confidence in me personally).
We manged our central Mercurial repositories for a small team on shared network drives (Windows environment) without any problems.
Mercurial managed the locks well and all the developers were happy.
On top of this, we also had a backup of the repositories from the shared drive to a backup system.
This setup worked well for over a year and was eventually replaced by putting the central repositories on a dedicated server that exposed them using hg serve. This was done to allow easier access for remote users, and also improved performance.
EDIT: An example on redirecting from httpd to hg serve.
The Mercurial hg serve is running with the following command:
hg serve --address 2.2.2.2 --port 8081 --prefix mercurial --accesslog /opt/mercurial/access.log --errorlog /opt/mercurial/error.log --webdir-conf /opt/mercurial/hgweb.config --pid-file /opt/mercurial/hg.pid --encoding utf8
In the httpd.conf
# Mercurial web server
ProxyPass /mercurial http://2.2.2.2:8081/mercurial
ProxyPassReverse /mercurial http://2.2.2.2:8081/mercurial
<Proxy http://2.2.2.2:8081/mercurial*>
Order deny,allow
Allow from all
</Proxy>
Any call to http://<my httpd host>/mercurial will be redirected to http://2.2.2.2:8081/mercurial
I hope this helps.
Related
I'm cloning openJDK source code to my local repo, and I'd like be sure that the file integrity has been maintained in transit.
hg clone http://hg.openjdk.java.net/jdk8/jdk8/
The Mercurial FAQ says that revlogs are checked against their hashes, "But this alone is not enough to ensure that someone hasn't tampered with a repository. For that, you need cryptographic signing." Does that mean I need to use
SSH like this?
hg clone ssh://hg.openjdk.java.net/jdk8/jdk8/
And to get SSH access, do I have to sign up as a contributor to the project? If so, is there a way to get a verified clone without becoming a contributor?
SSH provides transport encryption. It ensures the data cannot be altered in-transit from the OpenJDK repository to your computer.
The Mercurial FAQ is talking about signing the commits, which ensures that you can later verify that these commits have not been tampered with individually. It means an attacker cannot break into the OpenJDK servers or falsify a commit for upstream acceptance, adding in revisions that the project doesn't mean to be there. You would be able to recognise such revisions because they lack the right signature or are not signed at all.
SSH wouldn't protect you against such issues, because SSH doesn't care about the data it transfers. Malicious (altered or added) commits are transferred just as securely as valid revisions.
Signed commits is not something you as a consumer of the repository can add later. The OpenJDK project would have to build signing into their committing procedure from the start.
We have a huge (around 10GB) mercurial repository. Pulling everything will take around 3-4 hours.
Complete repo is also available on my colleagues machine.
Is there a way to efficiently clone the repo from his to my machine?
My first thoughts were to ,
hg bundle the entire repo on his machine and copy it to usb stick.
create a clone with just 1(very first) changesets from the server
Then unbundle the entire repo on my machine.
bundle and unbundle take lots of time.
Wondering if there are better ways to do it.
You can clone it right off the colleague's machine. He can run "hg serve", which will report the http address to clone from, then you run "hg clone http://xxxxxx:8000" where xxxxxx is reported from the other machine. You'll want a beefy network speed. Use --uncompressed flag if you are on a local LAN.
The speed dependends on a lot of factors.
Some things you could try:
Use hg serve with or without compression (like mentioned by Mark, already)
Use SSH with or without GZip compression (depending on the network speed).
Simply copy the folder containing the working folder and .hg repository folder using any means possible:
Copy it to a USB stick
Copy it over the network
There is some magic related to local files when you clone to a different folder on the same machine in regards of file links, but this does not apply if you copy the repository to a completely different computer.
So assuming those 3-4 hours is not because your network is slow, you should be able to copy it using the normal OS tools.
I want to do the equivalent of svn export REMOTE_URL with a mercurial repository. What I want at the end is an unversioned snapshot of the repository at the remote URL, but without cloning all of the changesets over to my local machine.
Also, I want to be able to specify a tag in the remote repository to pick this from. If it's not obvious, I'm building a release management tool that pulls from a canonical mercurial repository to build a release file, and it's slow right now because some projects have large, multiple-version binary files committed.
Is this possible? How would one go about it?
Its usually easier (if the remote HG is using the hgweb interface) to just visit the repo in your browser and download a .tgz / .zip / .bz2 of the tip revision. You'll see the links if the remote HG supports this.
If you want the repository, you need all of the revisions that went into the current tip for it to be at all functional.
There are options to hg clone that allow you to fetch a repository up to a certain revision, but none (that I could find) that allow you to get just the tip revision. What you are essentially asking for is a snapshot of the repo.
Edit: To Get A Snapshot
hg clone http[s]://url.to.repo repo.hg
cd repo.hg
hg archive ../repo-snapshot
cd ..
rm -rf repo.hg
The snapshot is now in repo-snapshot.
Yes, this does entail cloning the repo first, which is why I suggested seeing if the remote hgweb supports on the fly downloads of any particular revision. If it does, your problem is solved with something like curl or wget instead of HG.
If not, its good to let the original repo 'live' since you can update it again later via hg pull, then create another snapshot of a future release. This saves having to start over from scratch when cloning, especially for large repositories with lots of changes.
Also, Linux centric, but you get the gist. Of course, replace http[s] with the desired protocol as needed.
Is there any reason you can't maintain a mirror (updated in the background however often you want) of the remote repository on your local machine, then have the release management tool on your local machine run hg archive out of the local clone as necessary? If your concern is user-responsiveness, and not total bandwidth/storage consumed, this offsets the "slow" part to where you won't see it.
Tim Post noted that if you do have the hgweb CGI interface available, you can configure it to pull compressed archives down and unpack them (and the interface is consistent enough that you could script that via wget), but if you don't, core Mercurial doesn't have a lot of tools to help you, and the developers have expressed an opposition to trying to turn Mercurial into a general rsync-type client.
If you aren't afraid of playing with unofficial add-ons, you could have a look at the FTP Extension. That will force you to push from the server, however.
I wonder, if it's possible to create and serve to the clients Mercurial repository on the
some FTP folder with RW access . Did someone do a thing like that ?
Thank you in advance.
Just for the sake of completeness, because I had the same problem and feel that there is another, much simpler solution:
Mercurial cloning on local folders "just works", so if you mounted the ftp as a local folder or drive, you could just push/pull/clone to that (and have your repository end up on the ftp).
On Windows, you can e.g. use FTPUse or NetDrive to have your FTP folder mounted as a local drive, the former is free but a CLI tool which removes the virtual drives if the program is closed, the latter has a GUI but is only free for personal use and doesn't work (yet) on Win8. I don't have a Linux machine at hand now, but you should be able to achieve the same using ftpfs.
Once you did it (and your ftp server is now mapped e.g. to f:), you can simply use that virtual drive (or any subfolder) as a remote target for your mercurial operations. Works like a charm for me.
All things are possible. But that would be hard.
The bit where the network transport matters is when cloning a repository, and the standard ways of doing that depend on either serving over HTTP, or having SSH access to the repository host. There's no FTP-based transport for cloning as far as I can see.
If that's the only sharing mechanism you have available, then you could probably work something out using Mercurial bundles. The procedure would be something like the following:
Commit your edits to a local repository
Make a bundle using hg bundle --all my-bundle.hg
FTP my-bundle.hg to the server
The other users of the repository can then use FTP to retrieve the my-bundle.hg file to their local machine, go to their local copy of the repository, and then hg pull my-bundle.hg to pull in any revisions which are in the bundle but not in the local repository. When they want to share their changes, they make a fresh bundle as above, and push that back to the server. The --all option puts all of the changesets into the bundle file -- you can be cleverer and only export 'recent' changes, but that gets a little more complicated and risks losing changesets: using --all is brutal but fail-safe.
There's obviously a fair amount of scope for confusion here, and race conditions (timestamped filenames might help), and hair-pulling-out, and your users would doubtless appreciate some scripts to make this easier, but if all you've got available is an FTP server, you don't have very many options.
Good luck.
This question on SuperUser might be interesting. The core idea seem to evolve around running a background process that synchronizes a local folder with a remote ftp folder. Which might of use to you.
But I dont know what happens when more than one user tries synchronize at the same time. Since using this approach bypasses all the protection that mercurial has regarding locking the tree and such.
We come from a subversion background where we have a QA manager who gives commit rights to the central repository once he has verified that all QC activities have been done.
Me and a couple of colleagues are starting to use mercurial, and we want to have a shared repository that would contain our QC-ed changes. Each of the developers hg clones the repository and pushes his changes back to the shared repository. I've read the HG init tutorial and skimmed through the red bean book, but could not find how to control who is allowed to push changes to the shared repository.
How would our existing model of QA-manager controlled commits translate to a mercurial 'central' repository?
HenriW's comment asking how you are serving up the repositories is exactly the right question. How you set up authentication depends entirely on how you're serving your repo (HTTP via Apache, HTTP via hg-serve,, ssh, etc.). The transport mechanism provides the authentication and then mercurial uses that with the commands from Mr. Cat's link (useless in and of themselves) to handle access control.
Since you didn't mention how you're serving the repo, it was probably someting easy to set up (you'd have remembered to mention the hassle fo an apache or ssh setup :). So I'll ugess those two:
If you're using hg serve then you don't have authentication setup. You need to use apache, lighttp, or nginx in front of hgweb or hgwebdir to provide authentication. Until you do the allow_* and deny_* options are strictly everyone or no one.
If you're using ssh then you're already getting your authentication fromm ssh (and probably your OS), so you can use the allow_* and deny_* directives (and file system access controls if you'd like).
serverfault.com has a relevant question and links to the Publishing Repositories Mercurial Wiki page. The first shows how to configure per-repository access when using hgweb on the server. I get a feeling that you're using ssh which the wiki page labels as "private" and am therefore inclined to believe you would have to fall back to file-system access control, i.e. make all the files in the repository belong to the group "commiters", give group members write access and everyone else read/only.