I do mostly small projects as a part of my research at the university, and have been using our SVN server, and also played around with Mercurial in connection with SourceForge.
I am wondering if running Mercurial or any other kind of version control on my home server would make sense. The SVN server I use at work is behind the university firewalls, and between the IT-department of the building and our IT-responsible in our department I think it's much of a hassle of starting new projects on the server and coding when I am at home. I have a Drobo FS (NAS) at home which I could imagine using for running a version control server, so that I can easily reach my code wherever I happen to be, without having to put my code on a 3rd party server.
What are the pros/cons of this approach compared to getting an account at a project hosting site with support for private projects? Is it feasible? If so, would it imply a significant maintenance workload?
The pros are that you are in full controll of your server:
you can set it up any way you want it
noone else has access to your source/project
The cons are that you are the only one that is responsible: you have to
ensure the proper setup
do maintenance
perform upgrades
ensure protection against power outages
ensure adequate security measures
ensure reguar back-up
etc.
Of course you should do it as soon as you have projects you don't want to open on servers like github.
Most small private teams have a source server, no reason not to have one. For example gitolite is easy to install and use (I don't know for Mercurial but I think there is an easy to install solution too, probably even easier).
A side effect would be you could use something a little more modern than svn, for example a decentralized vcs you could use at home and synchronize with your server (no need to use a server for every manipulation when using mercurial and git : just set up a local repository and push to your server from time to time).
Whenever you have distributed development (either because of a team across different geographical sites, or because you develop from different sites), a DVCS makes sense.
Don't forget that, on one site, if your team members have access to the git/mercurial repo filesystem (ie the shared path of the repo), you don't even need a server at all. Those DVCS supports filesystem protocol access (albeit without authentication or authorization), aka local protocol.
You can also share your project across sites with an external service like BitBucket (supporting both public and private projects, for Git or Mercurial)
If you have write access to university network (through an USB key for instance), you don't even need to access that external service (BitBucket could be blocked, it wouldn't matter).
A git bundle allows you to export a git repo as one file, from which you can pull from as it was a repo.
So you have various options in order to access/manage a repo from different site, without having to register yourself to a centralize server (like your SVN), which you couldn't access from any site (like from home).
Related
Does anyone know of a solution (web hosted or otherwise) for a source code control system that would work well in a university environment where information technology is the focus? We'd like to offer it as a campus-wide "version-control service", much like universities do with an email service. Specifically, I'm talking about the following peculiarities:
There are a large number of new repositories created/managed each semester. Any programming course or research project could require students to use source code control, in various source code environments (including .NET, Java, C++, LaTeX).
Students should be able to create and manage themselves the repositories. Involving an administrator/instructor/etc. is not scalable otherwise.
Repository storage should be secure (private), and archivable for respecting intellectual property (preventing plagiarism, protecting research IP).
Any or all of the flavors of source code control (e.g., CVS/SVN/GIT) would be acceptable.
Remote access to repositories is essential. Student/researchers have freedom to work either in designated lab spaces or remotely. Marking of assignments can be done by instructors who've "checked out" the code anywhere.
If an academic license exists, it must scale for >500 students.
Many commercial/free products (web-based or otherwise) don't satisfy conditions #1 and #2, as they require superusers to administer accounts/repositories/accesses. Solutions such as Google Code, sourceforge.net, GitHub, etc. don't satisfy condition #3, as the repositories are always public.
Here's free one: http://gitlabhq.com/
You can add repositories over this tool.
For security you use RSA Keys.
And I would suggest to use Git. SVN and CVS are outdated.
GitHub would appear to satisfy your requirements. You can set up your own instance in your intranet; https://enterprise.github.com/
You could use git in the students private file storage if they have such a thing, git doesn't require hosting other than a place to store files.
Redmine (SVN, CVS, Git, Mercurial, Bazaar and Darcs)
UberSVN (SVN)
Private Assembla (?) (SVN, Git, Mercurial)
One solution I use is to create a master GIT repository in a Truecrypt variable size encrypted container. The container is placed in a Dropbox folder. The repository is cloned to the local hard drive which becomes the working directory. All the work is done and checked in on the local repository. I wrote scripts that mount the encrypted container, pushes/pulls the local repo to the master repo and dismounts the encrypted container. Dropbox detects the changes in the encrypted container and syncs it to the Dropbox server. Security is maintained as an encrypted file is the only thing sent to the server. Only real way to ensure security is doing the encryption yourself.
All you need to set this up is a few scripts, truecrypt installed and a Dropbox account. Could probably write some basic software to automate some of the steps. To make it scaleable and low cost, the basic steps are still valid. Create a master and local repository, encrypt the master repo, work on the local repo and sync changes to the master, back up the encrypted master repo online or on a server.
I am trying a lot and i am not bale to get how this version control work in my scenario
I have the VPS server where i host php sites. Users have home directories in /home/users.
Currently users edit files via FTP and i have no control what they do. I want to setup version control system on VPS i don't know hoe to start . I mean
I will explain what i want , i may be wrong but please correct me.
How can i install VCS on my VPS server so that all directories in /home/users are version controlled. I don't know if its possible or not. I want that final saving place or repo should be /home/user/public_html so that when user commit then my live site should change. Now i don't know if VCS works that way or not.
Now how will my client computers connect that VCS server
Is it possible to have version control for one user i mean /home/user1/public_html and not for others
Now users will still have FTP details , can't they change files via FTP even if i use VCS
Please clear my doubts , i really want to learn VCS systems
Yes, it should be feasible. Expect to be storing some extra data as the whole history will be stored plus separate copy of the current version for the stored.
You have to decide which version control system you want to use. The most common options are:
Subversion
Git
Mercurial
Bazaar
If you or your users already have experience with one, than it's probably best choice.
You want to:
Install the version control system of choice and create a post-commit hook to check out each version into the target directories.
Clients will commit into the respository. All the systems support access through restricted ssh (users log in using public key and the key is set in .ssh/authorized_keys to only allow one particular command). Some also have HTTP(s)-based method (special Apache module for Subversion, CGI script for Mercurial, Bazaar and Git).
Yes; the hook script will check out what you tell it to. You can implement it to checkout for all users, listed users, users in a group, whatever you need.
Turn the FTP server off.
Usually the workflow is that you have a repository with all the revisions and changes. This uses a special format, there is no point in directly accessing these files. The repo is typically accessed thru WebDAV interface (running as an apache module), or running a standalone server (with it's own protocol).
Users commit their changes to the repo, then can export the latest revision (or one of their choice) to their publicly accessible *public_html* directory. This involves them interacting with the VCS and knowing (and caring) about it.
A simpler setup can be that the *public_html* contains a working copy and they interact with it thru conventional FTP. (You have to make sure that the VCS's files for example the .svn folders can not be accessed by the general public). This way you can expose the VCS functions (basically commit and rollback) to your users thru a web interface (you write a small PHP script that does the commit and update for your them).
Incremental backups: a completely different story
As I understood you probably need something more like incremental backups, for example rsync. Each time a user closes an FTP connection you can initialize an rsync backup. It has flexible options, you can have all the changes for the last X days, or last X FTP sessions, so the user could roll back after an accidental upload. (It can be used with a remote or local storage for backups).
VCS (Version Control System) is just a class of software: You need to select one before you can implement it. In your case you probably want subversion, or one of the DVCS (Distributed Version control system) (git or mercurial).
It sounds like what you want is some kind of automated deployment system for your websites, which is certainly possible.
Disabling ftp is easy: simply stop the ftp server from running: ftp is insecure and the servers are often dangerous themselves.
Have a look at how Branchable works. They have specific web framework (ikiwiki), but the underlying principle of keeping the web sites in version control (git) is the same and all the software they use is open-source including the scripts that bind it all together, so you can look how it works.
I have a CakePhp Website that is currently live. I would like to keep working on the site, without impacting the deployed site.
What is the best way to keep a production version separate from a deployed version, and then merging the two when appropriate?
Currently, I am using Git for version control.
Thanks!
First thing, get to know a version control system Subversion, Git, Bazaar, Mercurial are some examples. They are a safety net that can save your bacon because they save EVERY change to EVERY file in your fileset.
Then, typically I have a local development server and also a subdomain (staging.example.com) on the production server. I then do my heavy development on the local development server. Then I use SVN to archive all my site changes. Then, using a shell account on the production server I check out the new version of the software to the staging subdomain. If it works ok there, I can then update the live site using just a single SVN check out.
I've also heard of people placing a symbolic link in the location where the site root should be (/var/www/public_html) that points to the live directory (/var/www/site_ver_01234) , then set up the new version in a parallel directory (/var/www/site_ver_23456). Finally, just recreate the symbolic link pointing to the new version's directory. The switch is instantaneous and transparent. I'm sorry I'm not more clear on this method though, I read about it a while back but never tried it myself though.
I've also looked at Bazaar (another version control system) that has a plugin that automatically ftps any changed files to a given server every time a version is checked in.
The general idea, first of all, is to use a version control system. Using this, you're developing your site on your local machine or with several people, having a central repository somewhere.
When you're happy with a certain revision and would like to deploy it, you "tag" it. That means you freeze the state of that revision and separate it from the continually evolving "trunk". What that means specifically depends on your version control system.
You then take that tagged revision and copy it to the live server. Possibly you may copy it to a "staging server" before to test it in another environment. This copying can be as simple as overwriting all existing files using FTP, or it can involve automated deployment systems which will take care of the details for you and allow you to roll back an unsuccessful deployment. If a database is involved as well, you're probably also looking at database schema migration scripts that need to be run.
Each of these steps can be done in many different ways, and you'll have to figure out what's the best approach for you. If you're not doing so already, start using a version control system such as SVN or git. Do it now! Then you might want to google or search on SO about different techniques to tag and branch using that system. For serious deployment, start with a keyword like Capistrano or one of its PHP clones.
I'd like to work on my own projects on different computers...on the road on a laptop, or at home on the desktop, or even at work. I'd like to keep the data relatively private, and I don't want to pay for private repositories on github.
Ideally, I'd host a git or svn repository on my web host, or something like that. Can I do that? Or is there a web services-based version control system out there that accomplishes the same thing?
I use beanstalk for my development (svn). You could also try github (git obviously).
I use beanstalk as well for about 2 months now, I'm very happy with it, it also has integration to lighthouse so I can close bugs/issues with commit to SVN.
I also have a local VPS server hosted and I installed the VisualSvn Server on it, it works great but it's a bit on the expensive side.
My hosting provider, Dreamhost, provides Subversion repositories (along with Trac). However, if you can install a repository depends mostly on your hosting provider and what features they allow. Some make it easy, others won't allow you to install what you need to even set one up.
currently my work-flow is as follows:
Locally on a machine I maintain a git repo on each website I am working on, when the time comes to publish something I compress the folder and upload this single file to the production server via ssh then I decompress, test the changes a move the changes to the live folder and I get rid of the .git folder.
I was wondering if the use of a git repo on the live server was a good idea, seems to be at first but it can be problematic if a change doesn't look the same on on the production server in comparison to the local development machine... this could start a fire...
What about creating a bare repo on some folder on production server then clone from there to the public folder thus pushing updates from local machine to the bare repo and pulling from the bare on the public folder of the production server... may anyone plese provide some feedback.
Later I read about capistrano http://capify.org but I have no experience w/ this software...
In your experience what is the best practice/methodology to accomplish a website deployment/updates?
Thanks in advance and for your feedback.
I don't think that our method can be called best practice, but it has served us well.
We have several large databases for our application (20gb+), so maintaining local copies on each developers computer has never really been an option, and even though we don't develop against the live database, we do need to do the development against a database that is as close to the real thing as possible.
As a consequence we use a central web server as well, and keep a development branch of our subversion trunk on it. Generally we don't work on the same part of the system at once, but when we do need to do that, or someone is making a lot of substantial changes, we branch the trunk and create a new vhost on the dev server.
We also have a checkout of the code on the production servers, so after we're finished testing we simply do a svn update on the production servers. We've implemented a script that executes the update command on all servers using ssh. This is extremely convinient, since our code base is large and takes a lot of time to upload. Subversion will only copy the files that actually have been changed, so it's a lot faster.
This has worked really well for us, and the only thing to watch out for is making changes on the production servers directly (which of course is a no-no from the beginning) since it might cause conflicts when updating.
I never thought about having a repository copy on the server. After reading it, I thought it might be cool... However, updating the files directly in the live environment without testing is not a great idea.
You should always update a secondary environment matching exactly the live one (webserver + DB version, if any) and test there. If everything goes well, then put the live site under maintenance, update files, and go live again.
So I wouldn't make the live site a copy of the repository, but you could do so with the test env. You'll save SSH + compressing time, plus you can check out any specific revision you'd like to test.
Capistrano is great. The default recipes The documentation is spotty, but the mailing list is active, and getting it set up is pretty easy. Are you running Rails? It has some neat built-in stuff for Rails apps, but is also used fairly frequently with other types of webapps.
There's also Webistrano, which is based on Capistrano but has a web front-end. Haven't used it myself. Another deployment system that seems to be gaining some traction, at least among Rails users, is Vlad the Deployer.