I am learning how I can install Mercurial on our team system, but I am not experienced enough to make some decision.
For our team, we have a server machine used as a repository. Every team member also has her/his own Linux RedHat installed machine. However, we do not do anything on our local terminals and we do everything on the server. Every member has a user directory on the server such as /home/Cassie, /home/john, ... and we save all our code and work there. When we turn on the local terminals, the GNOME system shows our personal files on the server not the local machine. Whenever everyone click the terminal application on desktop, it connects to her own home directory. Thus, we do not need to use SSH command to connect to the server. It is like the school multi-users system. Everyone has a user account and she logs into her own account to do her own work. I hope I can install a shared repository on that server and every one can do push, pull, etc. all kind of commands there.
1) Since we use a shared environment, does it mean that I need to install Mercurial on only the server and that is enough for everyone to do "commit", "push", "pull", etc. commands?
2) By installing only system-wide Mercurial, does it eliminate the ability to do local commit? If I would like to let everyone still have the "local commit" ability, how should I do it?
3) I have searched online. Some people mentioned that for a shared network server, it is impossible to have locks for any two users if they are trying to access the same file at the same time. Does it imply my situation?
In sum, we do all the work on the server. I hope to find a plan to have Mercurial control on a repository shared by everyone when everyone still has local commit ability and the repository still has some locks protection if any two users try to access a file at the same time. If this scenario is feasible, can I just install the Mercurial on the server or I need to install Mercurial for both servers and users machines? If it is impossible for the scenario, would someone please suggest me a plan to have version control for our system?
1) Since we use a shared environment, does it mean that I just need to install the Mercurial on the server and it is enough for everyone to do "commit","push","pull"..etc commands ?
If your users are logging into a shell on the server in order to do their work, then yes it is sufficient to have Mercurial installed only on the server.
2) By installing only system-wide Mercurial, does it eliminate the ability to do local commit ? If I would like to let everyone still have the "local commit" ability, how should I do it ?
Your users will presumably checkout from a shared "root" repository into their own home directory in order to work on the code. They will have a "local" copy of the repo in their home directory and will push into the shared root repository.
3) I have searched online. Some people mentioned that for a shared network server, it is impossible to have locks for any two users if they are trying to access the same file at the same time. Does it imply my situation ?
As long as your users are working within their own local copies of the repo, they will not interfere with one another. The only time a conflict may arise is when committing back to the shared root repository -- in which case the user will need to merge their changes and resolve any conflicts.
I would recommend reading carefully through Joel Spolsky's excellent Hg Init tutorial for a better understanding of how Mercurial handles "central" and "local" copies.
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
So I own a VPS server running CentOS, and decided to use git for deployment. Man! That's fun. Push, done!
I'm really happier than i was with the old ftp approach.
But I wish I could go further, today it deploys automagically all my files, but it doesn't even touch my db. And if I change it in the mods, I have to update it manually. So i was thinking about using some git hooks to do this also automatically.
By now I'm using one git hook at the server, it's a post-receive hook and basically copies files to the production directory when pushed to master.
The prerequisites for the DB deployment are:
It needs to go both ways, if i pull from db, and it's different from my local it should update my local db.
It should be based on modifications and patchs and not the dump of the whole db, this way i can work with the team without compromising other guys work.
I was thinking about keeping a db.sql on the version control, and make a script to analyze it on post-receive (on server) and post-merge(on local), so it can take the mods and apply, and i would keep a database of which mods were applied already (the script should run in both, client and server).
Any of you guys have already done something similar to this? What would you recommend?
Thank you very much already,
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 have about 100 000 files on office server (images, pdf's, etc...)
Each day files count grows about 100-500 items, and about 20-50 old files changes.
What is the best way to synchronize Web-server with these files?
Can any system like Mercurial, GIT help?
(On office server, I'll commit changes, and web-server periodically do updates)?
Second problem is, that on Web-server I have user-generated-content (binary-files) (other files).
Each day this users upload about 1000-2000 new files. Old files don't change.
And I need to backup these files to local machine.
Can any system like Merurial, GIT help in this situation?
(On web-server I'll commit these files by cron, and on local machine I'll do updates)
Thanks
UPD.
Office server is Windows Server 2008 R2
Web-server is Debian 5 lenny
The simplest and most reliable mechanism (in my experience) is rsync.
On Windows, however, rsync over ssh is badly broken due to issues with how Cygwin interacts with named pipes. Rsync over its own protocol works (as long as you don't care about encryption), but I've had lots of problems getting rsync to stay up as a Windows service for more than a few days at a time. DeltaCopy is a Windows app that uses the rsync tools behind the scenes; it seems to work very well, though I haven't tried the ssh option.
A DVCS is not a good solution in this case: it will keep the all history, which you don't always need, and will make any clone a massive operation.
An artifact repository like Nexus is much more adapted if you need some kind of versioning with integrity check associated with your binaries.
Otherwise (no versioning), a simple rsync like Marcelo proposes is enough.
Howto configure system to have one master and multiple slaves where building normal c-code with gmake? How slaves can access workspace from master? I guess NFS share is way to go, but if that's not possible any other options?
http://wiki.hudson-ci.org/display/HUDSON/Distributed+builds is there but cannot understand how workspace sharing is handled?
Rsync? From master: SCM job -> done -> rsync to all slaves -> build job and if was done on slave -> rsync workspace back to master?
Any proof of concept or real life solutions?
When Hudson runs a build on a slave node, it does a checkout from source control on that node. If you want to copy other files over from the master node, or copy other items back to the master node after a build, you can use the Copy to Slave plugin.
It's surely a late answer, but may help others.
I'm currently using the "Copy Artifact plug-in" with great results.
http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin
(https://stackoverflow.com/a/4135171/2040743)
Just one way of doing things, others exist.
Workspaces are actually not shared when distributed to multiple machines, as they exist as directories in each of the multiple machines. To solve the coordination of items, any item that needs distributed from one workspace to another is copied into a central repository via SCP.
This means that sometimes I have a task which needs to wait on the items landing in the central repository. To fix this, I have the task run a shell script which polls the repository via SCP for the presence of the needed items, and it errors out if the items aren't available after five minutes.
The only downside to this is that you need to pass around a parameter (build number) to keep the builds on the same page, preventing one build from picking up a previous version built artifact. That and you have to set up a lot of SSH keys to avoid the need to pass a password in when running the SSH scripts.
Like I said, not the ideal solution, but I find it is more stable than the ssh artifact grabbing code for my particular release of Hudson (and my set of SSH servers).
One downside, the SSH servers in most Linux machines seem to really lack performance. A solution like mine tends to swamp your SSH server with a lot of connections coming in at about the same time. If you find the same happens with you, you can add timer delays (easy, imperfect solution) or you can rebuild the SSH server with high-performance patches. One day I hope that the high-performance patches make their way into the SSH server base code, provided that they don't negatively impact the SSH server security.