20

I'm developing a web site in php in localhost and as modules of it gets completed, I upload it on the cloud so that my friends can alpha test it.

As I keep developing, I've lots of files and I lose track of which file I've edited or changed etc. I've heard of something as 'version control' to manage all those but am not sure how it works.

So, my question is: Is there an easy way/service/application available to me to track all the edits/changes/new files and manage the files as I develop the website. As Soon as I'm done with a module, I want to upload it on the cloud (I'm using Amazon Cloud Service). If something happens to the new files, I might want to get back to the old file. And maybe, in a click or two, I get to see the files which I've edited or changed since the last one I've uploaded?

Improve this question
1
  • 6
    There is a lot of suggestions on what version control system to use, and to honest, all of them are better than your current "manual" way.
    – Johan
    May 8, 2011 at 7:46

7 Answers 7

Reset to default
29

Software configuration management, of which Version Control is part, is a little more complex than keeping track of changes to files, although you can certainly start with that. But do read the Wikipedia articles linked above along with Joel Spolky's tutorial on Mercurial.

To start, choose one of Mercurial, GIT, or Bazaar, in that order, and install it along with tools for your IDE and operating system (I prefer Mercurial with HGE for Eclipse).

  1. Initialize a repository from your working directory (hg init with Mercurial)..
  2. Decide which files and directories you want to track and which not. The general rule is not to track files that are generated by compilers and other tools.
  3. Use the command to add the files and directories to the repository (hg add for Mercurial).
  4. Tell the tool about the patterns for the files you don't want to track (edit .hgignore for Mercurial).
  5. Perform a commit to track the original versions (hg ci).
  6. Perform a commit after each logical milestone, even if it's a small one.
  7. Add new files as you create them.
  8. Repeat the last two.
  9. Backup your working directory and the repository as frequently as reasonable.

With your files in the repository, you can know the differences between any two versions of a file or directory, or the complete project (hg diff), see the history of changes (hg hist), and roll back changes (hg up -r).

It is a good idea to tag (hg tag) the repository before publishing your code so there's an easy way of going back to exactly what you published for amendments or comparisons.

If you want to experiment with a different line of development, do it in a simple branch by cloning the main repository (hg clone) and not pushing back until the experiment is conclusive. It is as easy as having a different working directory for the experiment.

If the experiment is for a new, upgraded version then clone and then branch (hg branch) so you may keep all copies of the repositories updated without one experiment interfering with the other.

Linus Torvalds (who deals with tens-of-thousands of files and millions of lines of code in his projects) gave a talk at Google about why the tool can't be CVS, SVN, or any of the many free and commercial ones around; it is very much worth watching.

Improve this answer
6
  • 1
    I prefer Mercurial as well. I like the support in Netbeans because while you are coding it shows you every line that has changed since your last commit. It also color codes new/changed/unchanged files in the product tree. Which sounds like it would be helpful for the OP: I lose track of which file I've edited or changed. HGE may do this too, I have not used it.
    – JD Isaacks
    May 6, 2011 at 20:33
  • 1
    +1 for describing the process as well as part of how to use tools to do it.
    – Donal Fellows
    May 7, 2011 at 9:12
  • As a side-question, would the .xcodeproj file that Xcode uses for iOS projects be considered something to tell Mercurial to ignore, or is it important to keep the file in sync?
    – Kevin Yap
    May 7, 2011 at 18:14
  • 1
    @Kevin I don't know about Xcode, but the latest IDEs and tools have separate configuration files for overall project stuff (language and library versions, code formatting rules, dependencies, etc.) and user preferences (directories where I place stuff, panel layout, skins, font-size, personal signature). The former may be included in the repository if the team agrees. The latter should not be included, because an update from the repository would overwrite your preferences with someone else's, and that becomes quickly annoying and counterproductive.
    – Apalala
    May 7, 2011 at 21:32
  • 1
    @John: NetBeans does that for every VCS that it supports. At this point, it's just a basic feature of IDEs.
    – Mike Baranczak
    May 8, 2011 at 23:36
13

I would highly recommend Git. Learn about it here: https://lab.github.com/

If you don't like Git, there are other version control solutions. You might check out SVN.

Improve this answer
2
  • 1
    As an everyday user of Git, I'd like to add that it's extremely easy and intuitive to pick up the essential commands. And the support for it is great so you won't be lost when you look for help. I've used SVN but it wasn't as easy for me but it might be okay for a lot of users.
    – Muhammad Usman
    May 8, 2011 at 3:16
  • 1
    +1 Also consider: people choose to move from svn (a VCS) to git (a DVCS - d=distributed) but not from GIT to SVN (through choice).
    – Michael Durrant
    Jun 29, 2012 at 21:07
7

Is it just you?, use a DVCS

As counter-intuitive as it sounds, a Distributed Version Control System (mercurial, git, bazaar)is better to start with than a centralized system (svn, cvs). Why?, you install it on your machine and run your repository locally, and that's it. On a centralized system such as svn you need to set up you client and a server... and then, you need to be connecting to a server to store your changes.

With a DVCS its you, the local repository, and if you want, you can use a service like bitbucket.org or github.com.

IMHO, mercurial is a friendlier and equally capable DVCS to start with.

Are there others?, use a DVCS!

There are numerous advantages when using a DVCS for working with a team, the most important one in contrast with a centralized system is that there are no commit races and this is because, technically, each individual's repository is a branch, and when you share your changes those branches are merged for you and you don't even notice, meaning that instead of having a version history like this, where you have people funneling their work on a straight line:

enter image description here

You end up having something like this, where everyone just commits ad hoc:

enter image description here

Each one just worries about their own work while versioning (i.e. not racing to commit) and not worrying about a connection to a server just to commit.

Good luck

Improve this answer
1
  • 1
    +1 Very nice examples! You should edit to emphasise the absent pain in complex merge trees with modern tools.
    – Apalala
    May 8, 2011 at 22:55
5

To be short, there are many alternatives, among which Subversion (SVN) and Git seem most popular (thus easiest to find solutions on the web).

They both differ. SVN is simplier, but Git does not require you to have server to start with - you can control version locally.

Assuming you have Linux and wish to start using Git:

  1. Install Git
  2. Go to the directory and execute command 'git init'
  3. Learn how to add files, review changes, commit them...
  4. ...and to do more advanced stuff (reviewing logs,reverting changes, ignoring files, creating branches, merging them, creating and using remotes, using submodules, using SVN support etc.).

Hope this helps you to start.

Improve this answer
7
  • 1
    SVN does not require a server, but it does require that the repository be in a directory different from the working one. SVN and CVS are generally deprecated in favor ot tools like GIT and Mercurial which don't require a network connection for daily work and don't require a central repository for collaborative and distributed software development.
    – Apalala
    May 7, 2011 at 3:12
  • Don't you think this is actually identical to creating SVN repository server on localhost? What you need is to configure the central repository and maintain it and when you move your files you mus make sure the SVN repository is still accessible (don't even think about copying the whole central repository every time you move files to different machine). Also I do not think Subversion is deprecated (I am not talking about CVS though) - it is just centralized and in some cases it would be a better idea to enforce centralization.
    – Tadeck
    May 7, 2011 at 12:32
  • Apalala, some question: how Mercurial handles information which user authored specific change? In Git you can alter it and commit change as someone else, thus creating some mess (there is some feature to distinguish commiter from submitter, but it is not obvious enough). Has Mercurial solved this distributed-version-control-related issue?
    – Tadeck
    May 7, 2011 at 12:42
  • 2
    @Tadeck That's not the way Mercurial and GIT work in my understanding. In these, a single person is in charge of what goes into a repository, be it by commits, pulls, or patches. In distributed repositories, if someone has push privileges, then you already trust them with all your heart. Linus Torvalds explains it well in this talk: youtube.com/watch?v=4XpnKHJAok8
    – Apalala
    May 7, 2011 at 22:27
  • @Tadeck Regarding SVN, I used it, a lot, and I ended up thinking that it was no improvement over CVS (which at least has plain-ASCII repositories and is mature enough to never corrupt them). Again, Torvalds explains it well in the video I linked before. The inability to do work offline, and the inability to merge makes old SCM tools deprecated.
    – Apalala
    May 7, 2011 at 22:31
2

As Apalala suggest, I recommend checkout out hginit. Since you are new to version control you can skip the first page. That should give you a good intro, afterwards you can post on SO if you have specific questions.

Improve this answer
0

I'm gonna go against the majority opinion, and recommend Subversion. Subversion is easy to use, and it does all the stuff that individuals and small teams need. It's a mature product, so every IDE out there has good support for it. Yeah, it doesn't have all the features of Git. (I've never used Mercurial, so I won't talk about it.) But most developers don't actually need those added features.

Multiple repositories? I'm sure there are some legitimate uses for those, but I've never run into them.

Being able to make local commits, without network access? That's nice to have, if you happen to be making several discrete changes, and you can't access the repository server - but honestly, how often does that happen?

Git does make it easier to deal with branching and merging. But for a one-person team, that's not such a big deal.

For something on the scale of the Linux kernel - yeah, use Git. For the rest of us, Subversion is good enough.

Improve this answer
3
  • Downvoting. The features of Git that aren't in SVN (such as lightweight branching and easy merging) are helpful, perhaps even essential, on small projects as much as on big ones.
    – Marnen Laibow-Koser
    Jan 20, 2018 at 8:59
  • 1
    @MarnenLaibow-Koser Yeah, that was my opinion at the time, but after using Git professionally for several years I'd have to agree with you.
    – Mike Baranczak
    Jan 20, 2018 at 13:09
  • Excellent! You will be assimilated. :D
    – Marnen Laibow-Koser
    Jan 20, 2018 at 16:08
-1

I think a Distributed Version Control System will do well. Commonly suggested choices are Git and Mercurial (Hg). Graphical tools may be helpful, for Mercurial I recommend TortoiseHg.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.