I'd need to keep a record of everything that happens with some repositories. By default I can keep a record of merging and commits, but I'd need a record of cloning, pulls, authentication, etc.
Is there a way to keep this logged somewhere?
Cloning, pulling, and authenticating are not part of a repository's history or state - all of that data is intentionally not tracked or pushed around by Mercurial.
In fact, Mercurial doesn't handle this behavior itself, it offloads this (particularly authentication) to the web server handling such requests. What you can do is look at the logs the server records. How this is tracked is very much server specific, but essentially you'd look at the access logs and see what is being requested.
Mercurial provides a lightweight web server hg serve for handling limited numbers of requests, and you can configure where both access and error logs are written to by this server with the -A and -E flags respectively. See hg help serve for more.
You could play with Mercurial's hooks and maybe log clones and pulls via that method, but authentication is completely transparent to Mercurial, so logging that must come from the server.
How are people accessing the repository. If it's over ssh you could easily log the command line that comes in via ssh. If it's over HTTP you can use your weblogs as a pretty fair record.
Mozilla has an open source 'pushlog' (example: https://hg.mozilla.org/mozilla-central/pushloghtml ) that they use to record all writes. You could probably easily tweak that code to record all reads too.
Related
Forgive me if this question sounds ridiculously naive, but I don't seem to be able to find a straightforward answer to this anywhere.
I am considering using Mercurial for source control on a small (2-3 developers) project. I like the idea of not having to subscribe to a central repository, and I like that everyone effectively has a complete copy of the project. What I don't understand is how the Mercurial clients communicate changes to each other. Does it require opening a specific port or something similar?
Any pointers to help on Mercurial or comments from people who have used it would be gratefully received.
Mercurial can access remote repositories in a number of ways. The main ones are:
File access (i.e. look at the repo at this path)
HTTP / HTTPS (i.e. look at the repo being served at this web address)
SSH (i.e. log into this machine / user, and look at the repo at this path)
The first only really works if your team is all working on a shared file-system, but is also useful if you personally have multiple clones that you want to move information between.
HTTP is how you would access something like Bitbucket, or some other "available to all" server. You can set-up a temporary server on a machine with the command hg serve, and that's useful if you need to share with a colleague quickly and don't care about security, but normally HTTP Mercurial servers sit behind Apache, or some other web server software.
An SSH based set-up is just a machine running an SSH server which has Mercurial installed. Mercurial logs on to the machine, and invokes hg remotely. The local hg and the remote hg then talk over the link. Very easy to set-up in my opinion. Credentials are all handled in normal SSH ways.
Further reading:Publishing Repositories
I'm migrating a few projects from SVN to Mercurial and I'm not sure how to address this issue: because we are working with MVC 3, we have some SQL connection strings stored in our Web.config file.
Since TortoiseHg automatically starts a wide-open web-server when you click "Web Server" from the context menu, I'm looking into ways to restrict it or lock it down, but I haven't been having any luck. We obviously don't want anyone being able to browse or pull, which is enabled by default. While the simplest solution is just to not run it, it is entirely possible that a developer accidentally clicks it while trying to synchronize or clone, clicks X to close it, and then ends up with his local server without a clue.
How do other developers address this? Am I missing something? I've thought about pushing out a GPO blocking :8000 remote access, but there's nothing stopping a dev. from scrolling up and changing the ports or something silly.
After all clarifications, I still believe you're trying to solve the wrong problem.
hg serve is a legitimate tool that can be used to pull changesets between developers on the same network when it's too early to push those changesets to the server. It may or may not fit into your workflow, but I don't think the problem lies there.
If you expect malice, than nothing prevents any developer to expose the sensitive information in the Web.config (and, by the way, the source code itself) to the third party even you somehow block hg serve.
On the other hand, if you expect carelessness, then you should instruct the developers not to use hg serve, or stop storing any sensitive information there, possibly both.
First off, I've been staring at page after page of solutions but none of them seem to fit the situation I have.
I have web developers all around the country using Windows workstations with Eclipse. We decided DVCS was best for us because the centralized system just isn't working (Serena: slow network connections takes forever to check in... they don't do it because it's not "streamlined", etc.)
We use Eclipse to edit and modify files on a development server in a different state. (Most DVCS scenarios assume you have a web server setup on your workstation or are doing binary executable development.)
What I'd like to try is to have a local repository for developer changes and "feature play" but automatically keep the development repository up to date. I thought of using Mercurial hooks to automatically pull/update/merge/push but that requires the developer to commit every time they want to test a change. (in order to fire the hook to upload their file to the development server.) It would be ideal to have this automatically happen on file saves because it's already an issue with training people to use version control (mainly because it's PITA slow currently with the WAN and virtual locations. Getting the WAN upgraded is not an option.)
My guess is that I'm going to have to setup Unison or something to keep the developer's repository synced to the development server as if it were a local copy and that of course would sync with the other developers. I was trying to find out if anyone had a solution that's streamlined/simple for keeping all developers up to date while allowing them to version control at will (easily.)
This is what branches are for. Have a branch called "unstable" and set your development server up with a repository that auto-updates on commits/merges to only that branch (via hook). Individual developers are free to work on feature branches and commit locally. When something is ready to be shared, the developer merges their changes into the "unstable" branch and pushes that branch to the development server/repository.
I manage my deployments this way. My Web server virtual host web root points to a Mercurial repository/working copy. When something is ready to go out, I merge it into the "stable" branch and push "stable" to the server. The repository hook updates the files on the virtual host with the new changes.
[hooks]
changegroup = /usr/bin/hg update stable >&2
I've only been doing this for a month or so but it's been working like a charm.
Also, +1 on checking out Hudson/Jenkins. What you're looking for is called "continuous integration" (CI) and Hudson and Jenkins make that happen.
If you can't have a development server on all workstations, then maybe using Test Driven Development with some sort of Unit Test framework for your language would work - most of those don't require a full server implementation to be able to write and test your code. It would require a change in paradigm but you'd sure get better quality of code out of that.
We're very happy with mercurial, but we had to change our habits... and it took some time
Each dev has now a test platform locally. Commits are made through branches and nothing is pushed before tests have been validated locally
Then, Hudson is our friend. To integrate teams works, each commit results in a build that tests the integrity of the app. Red signify rollback and return to the dev. Green is cool
Devs are here to commit 'sane' code and integrate by team to the central repo. They must decide when it's the time to push. No synchronized task can deliver them from this burden. When I see all the errors that can happen, even if each push choice is made consciensciouly by a human, I can't imagine if changes happened automatically on each file save
Good experience with Mercurial...
You say that you want to have a local repository for developer changes, but automatically push any changes to the server. If you cannot have a local dev environment to test changes on, what is the point of having local development branches? If your testing must be done on the development server, there is no way I can think of to allow for "feature play" in local repositories while maintaining any kind of sanity on your development server.
Your best bet in this scenario would probably be branching on the development server and having the server checkout different branches to test different features (hg update -C feature-blah). The default state for the server's repository should be a checkout of the main "devel" branch (hg update -C devel), and when any features or bugfix branches are verified as working they are merged back into "devel" and the server's repository updated from that.
Edit to clarify: your developers would either checkout from "devel" or from a feature branch to their local machine. They would then make any edits and push it back up to the server, and then switch the server's active branch to the newly-updated code.
Also, I am assuming from your other comments that there is only one dev server and it is only able to run one version of the code at a time. If this is not the case, my answer makes no sense at all.
I'm a big fan of backing things up. I keep my important school essays and such in a folder of my Dropbox. I make sure that all of my photos are duplicated to an external drive. I have a home server where I keep important files mirrored across two drives inside the server (like a software RAID 1).
So for my code, I have always used Subversion to back it up. I keep the trunk folder with a stable copy of my application, but then I create a branch named with my username, and inside there is my working copy. I make very few changes between commits to that branch, with the understanding that the code in there is my backup.
Now I'm looking into Mercurial, and I must admit I haven't truly used it yet so I may have this all wrong. But it seems to me that you have a server-side repository, and then you clone it to a working directory in the form of a local repository. Then as you work on something, you make commits to that local repository, and when things are in a state to be shared with others, you hg push to the parent repository on the server.
Between pushes of stable, tested, bug-free code, where is the backup?
After doing some thinking, I've come to the conclusion that it is not meant for backup purposes and it assumes you've handled that on your own. I guess I need to keep my Mercurial local repositories in my dropbox or some other backed-up location, since my in-progress code is not pushed to the server.
Is this pretty much it, or have I missed something? If you use Mercurial, how do you backup your local repositories? If you had turned on your computer this morning and your hard drive went up in flames (or, more likely, the read head went bad, or the OS corrupted itself, ...), what would be lost? If you spent the past week developing a module, writing test cases for it, documenting and commenting it, and then a virus wipes your local repository away, isn't that the only copy?
So then on the flip side, do you create a remote repository for every local repository and push to it all the time?
How do you find a balance? How do you ensure your code is backed up? Where is the line between using Mercurial as backup, and using a local filesystem backup utility to keep your local repositories safe?
It's ok thinking of Subversion as a 'backup', but it's only really doing that by virtue of being on a separate machine, which isn't really intrinsic to Subversion. If your Subversion server was the same machine as your development machine - not uncommon in the Linux world - you're not really backed up in the sense of having protection from hardware failure, theft, fire, etc. And in fact, there is some data in that case that is not backed up at all - your current code may exist in two places but everything else in the repository (eg. the revision history) only exists in one place, on the remote server.
It's exactly the same for Mercurial except that you've taken away the need for a separate server and thus made it so that you have to explicitly think about backing up rather than it being a side-effect of needing to have a server somewhere. You can definitely set up another Mercurial repository somewhere and push your changes to that periodically and consider that your backup. Alternatively, simply backup your local repository in the same way that you'd back up any other important directory. With you having a full copy of the repository locally, including all revision history and other meta data, this is arguably even more convenient and safe than the way you currently do it with Subversion.
The "hidden" .hg directory stores all of the local commits. You can back up this directory using a standard backup program.
The changes get to the remote directory only when you push. Commits stay local, but you get them if you clone your repository. Then, yes, if you want your things to get to the server repository you have to push to it "all the time".
On the other hand, nothing stops you to have several machines and push content from one to another. Every mercurial repository can turn itself into a server in a matter of seconds typing "hg serve".
I'm not sure it really answer to you question, but I too am a big fan of backup and manage things this way with many clones of my repository (I also use massively mq to work in patch mode but that's another story).
PS: as a sidenote, I'm considering to use mercurial as a tool for filesystem backup. The only thing that bother me is that for this purpose I would prefer to disable the diff feature and treat all files as binary, but that should be easy.
My team has a local development network which is not physically connected to any outside network. This is a contractual obligation and CANNOT be avoided. We also have to coordinate with a team which located halfway across the country and, as previously implied, has no direct network connectivity to us. Our only method of transferring data involves copying data to a USB disk and sending via email/ftp/etc.
NOTE: Let's not discuss the network connection issue or the obvious security flaw with the USB disk access. These issues are non-negotiable.
We're still convincing the external team to use Mercurial (currently don't use ANY SCM). Assume for the rest of this question that they're using Mercurial. We're going to force their hand any day now.
We switched to Mercurial in hopes of being able to utilize the distributed nature to better sync w/ the external team. Internally, we're using Mercurial much like a central server SCM. Each developer clones from a master repo on your integration server. Changes are pushed/pulled from this central location.
Here lies the actual question content:
What is the best way to communicate changes to the remote team (assuming they're using a similar Mercurial setup to us)? Should I have a local master repo for local push/pull), and a local integration repo for remote push/pull? How can I best avoid complicated merge issues that will arise? If we use Mercurial bundles to push changes, who will do the merges and against which repository?
You can basically use it in exactly the same way as if you were online.
You just need to replicate the remote repo locally and unbundle every changeset they send you in it. You should never push your changes directly into the local-mirror (it should always reflect the state of the remote team).
Afterwards you decide what you want, doing merges on your side or on their side, it doesn't really matter.