Here is a real version control system dummy! proper new starter!
The way I have worked so far:
I have a Drupal-6 web project http://www.blabla.com and making development under http://www.blabla.com/beta . I’m directly working on blabla.com/beta on server. nothing at my local, nothing at anywhere else. Only taking backup to local, time to time. I know horrible and not safe way :/
The new way I want to work from now on:
I decided to use Mercurial. I have one more developer to work on same project with me. I have a blabla.com Drupal-6 project on bluehost and making development blabla.com/beta. I found out http://bitbucket.org/ for mercurial hosting. I have created an account.
So now how do I set up things? I’m totally confused after reading tens of article :/
- bitbucket is only for hosting revised files? so if I or my developer friend edit index.php, bitbucket will host only index.php?
- from now on do I have to work at localhost and upload the changes to blueshost? no more editing directly at blabla.com/beta? or can I still work on bluehost maybe under blabla.com/beta2?
- When I need to edit any file, do I first download update from bitbucket, I make my change at localhost, update bitbucket for edited files, and uploading to bluehost?
Sorry for silly questions, I really need a guidance…
Appreciate helps so much! thanks a lot!
The main service of bitbucket is to host files under revision control, but there is also a way to store arbitrary files there.
I a typical project every file which belongs to the product is cheked into revision control, not only index.php. see this example
Mercurial does not dictate a fix workflow. But I recommend that you have mercurial installed where you edit the files. For example then you can see direct which changes you did since the last commit, without to need to copy the files from your server to your local repository.
I absolutely recommend a workflow where somewhere in the repository is a script which generates the archive file which is transmitted to the server, containing the revision of the repository when the archive got created. This revision information should also be somewhere stored on the server (not necessarily in a public accessible area), since this information can get very handy when something went wrong.
There are several different approaches to get the data to the server:
hg archive production.tar.bz2), this is the most secure variant, since it does not depend on any extra software on the server. Also depending on how big the archive is this approach can waste lots of bandwidth.hg exportlocally there into the production areahg fetchfrom bitbucket(or any other server-accessible repository)hg pushfrom your local working copy to the server (andhg updateon the server afterwards)The last two points can expose the repository to the public. This exposition can be both good and bad, depending on what your repository contains, and if you want to share the content. When you want to share the content, or you can limit the access to http://www.blabla.com/beta/.hg, you can clone directly from your web server.
Also note that you should not check in any files with passwords or critical secrets, even when you access-limit the repository. It is much more save to check in template files (with a different name than in production), and copy-and-edit these files on the server.