Base logic of working with Source Control at localhost + Mercurial

I'm pretty new at Mercurial - actually new at source con开发者_JAVA技巧trol.

I have projects at localhost, which is ~/mamp/htdocs. I want to work all local. There is a point I'm confused about:

I should keep repository at a different path than my htdocs I think, so I created "/reps/" folder and creating folders for each project under here, and copy all files from htdocs project folder to reps.

for example; project01

copy files from ~/mamp/htdocs/project01/ to /reps/project01/

But I work at localhost (htdocs) for changing files, etc. so how do I relate these changes to /reps/?

Obviously I'm missing some very obvious point about Source Control. Did I make a wrong start?

All the tutorials I found online requires some kind of base knowledge, I guess; none of them tells anything from meaning zero point! :/

The simplest way, if you want to edit your files in ~/mamp/htdocs/project01/ (because I also agree that it would be good to have some kind of staging area where you could test your changes before deploying them to the production server, but maybe it is precisely your machine which is the staging area, so everything's ok then :-)) is to:

1. Install Mercurial
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (whatever you want to manage)
5. hg commit -m"initial version"

After you have done hg init, there is a repository in a .hg dir under ~/mamp/htdocs/project01/ ! It is not possible to avoid this (yet at least) with hg: if you have sources in project01 you need to have a repo in project01. And it's sufficient because you can benefit from version control with just that, whenever you change a file, you can commit it and give a log message to tell the system what you have done, e.g.,

• <edit> a.html
• hg status (will tell you the currently modified files)
• hg diff (will tell you the differences with the saved version)
• hg commit -m"what-has-changed-message" (save a new version)

Even if it is not necessary to have another repo elsewhere (e.g., in /reps) if you want to, for instance to have your data in a backuped zone, then you could just clone the one in $HOME:

• cd /reps
• hg clone /home/name/mamp/htdocs/project01/ project01

Which will get in /reps/project01 an exact copy of what you have done: all your changes and all your log messages. Now if you do that, whenever you do "hg commit" to save a change in your primary repo, you also need to do "cd /reps/project01" and "hg pull" in order to forward the changes to /reps if you want it to stay synchronized.

Hope it is simple enough..

There are many different approaches / methods. Here is how I work:

1. Development: I check (clone in mercurials case) out my files to my 'development environment' to work on them then commit/push/etc. at the same place.

2. Next Stages: Once I think they are ready for user testing / production / or whatever your next stage is, then you can either distribute your code as a

   2a. package (could be a simple zip of your latest files) or

   2b. check them out into that next stage directory.

3. Other Usages: Once you are comfortable working with the main use scenarios, then you should consider other revision control usages like tagging, branching and merging

You should normally keep your VCS (version control system) and its files separate from your production web server environment (which is what I infer you are asking about given the mention of htdocs).

Many (at least old time) web systems have a staging area where you copy the material from the source system, which you can check carefully using a second (not publicly accessible) web server. When you're confident that the code is correct, you can move it into production.

This scenario has three areas:

• Working (development) area with VCS, etc; perhaps accessible via yet another web server).
• Staging area (no VCS, no public access; testing and validation).
• Production area (no VCS, public access).

It sounds a bit as if you are conflating these three - a common scenario in my limited experience. Even if you decide to do without the staging area, you do need to separate your development and production systems. And the VCS (Mercurial) is used in the working area.