Version control: accepting a project without any

Question

I recently took a project without version control. I have no experience with version control. I feel that this is the only way to go with this project (and probably some future projects now I think about it - I always trust myself too much).

My question is: where to start with implementing version control in an already running project? Whereas I did not use version control until there really are two separate questions:

• Since version control
• Implementing it on an already project

For the background, a project is a php / mysql-based website using javascript bits, I am working on a XAMPP server (Windows) and I am very interested in exploring this new world of version control!

Answer 1

Congratulations, you are heading in the right direction!

First you need to choose a version control system. My current favorite is Git. Unfortunately, I don't think Git is a simple introduction to version control. I also used Subversion and Perforce.

Subversion ( http://subversion.tigris.org/ ) runs on many platforms, is used in many projects, and has some useful GUI tools (see for example TortoiseSVN on Windows). Command line tools are also available. It is also free. You can run it in "local file system" mode, which means that you do not need to configure a separate server. It goes far from the roots of "better than CVS."

Perforce ( http://www.perforce.com/ ) is pretty nice. Its implementation on Windows seems to be the best (the last time I checked, their cross-platform GUI was pretty lousy). First of all, you use the graphical interface to interact with it, although again there are command line tools. This is commercial software, but open source projects can obtain free licenses by contacting the company. The biggest resistance is that you need to configure the server. To get started, you can start the server in the same field that you are developing, but this is probably a bad idea in the long run. I found that Perforce is very well suited for teams from 2-8 people; I do not know how well it will work with a lot.

The great advantage of Git ( http://git-scm.com/ ) is that it requires virtually no configuration. After installation, you can run git init in any directory to create a new Git repository. The history of changes is stored inside the project directory. You can start with only local version control, and you can scale from there. If Git seems scary, you can also check Mercurial ( https://www.mercurial-scm.org/ ). I have not used it, but I understand that it shares some of the same fundamental principles as Git.

Avoid CVS. This is on its way, and no new project should use it if they do not need it.

Adding a control source to an existing project is simple. The difficult part would be to guarantee that everyone would use the source control. If you work alone, then this is just a personal discipline. If you are part of a team and some people have reservations, you will have problems. Try to get everyone on board and be on hand to try and answer their questions. If people do not know how to use the tool, they simply will not use it.

Answer 2

Start here: http://svnbook.red-bean.com/

I found SVN to be the easiest version control system, especially for beginners. It's pretty easy to get started; the only real solution you need to make is to place your things. There are a couple of free svn servers, but if you are really serious about your work, you should host your own.

Answer 3

The first thing to do is choose a version control paradigm (centralized and distributed). To answer this, you need to take a look at your team and how you are going to handle registration, checkout, merging, and branching. After choosing a paradigm, you can choose a version control system. The main systems are Subversion for centralized version control and Git and Mercurial for distributed version control.

If the project works live and works, then this should be your initial registration for any version control that you use. You need a reliable baseline that you can return to and have 0 work to deploy what works. If your project doesn't work ... well, good luck. You might want to register to start using version control, and then decide how you want to continue (either get the project in a stable and efficient state, and then restart the repository or complete your initial registration as a broken system).

If the rest of the team does not see the benefits of version control, I would recommend installing your own system on your computer and at least using it for your own work.

Answer 4

Step 1: Download Mercurial .

Step 2. On your favorite command line, go to the root of your source directory and type hg init .

Step 3: do a make clean or equivalent (i.e. all you need is a source, non-generated files).

Step 4: Type hg addremove .

Step 5: Enter hg commit .

From now on you can:

• Examine the changes between your last commit and now: hg diff or hg status .
• Make breakpoints in your code: hg commit .
• Return to previous breakpoints: hg update -C -r 0

Congratulations, now you are using version control: it really is not that difficult, and it is very, very useful (if not for any other reason, than you can look at the changes you made to see if they make sense).

At some point, you probably want to know about branching (only if you have a backup of your repository on another machine), after which you can refer to the documentation or book .

Answer 5

Be prepared for some resistance from management and / or your peers. Management may not want to invest resources for the repository machine - these things need to be installed, saved, backed up, etc. Or they may object that you are wasting time on “extras,” such as RCS.

Your colleagues, especially if they are not familiar with any RCS, are likely to resist using it or complain that it is too difficult to use. There, the learning curve for any new tool and version control system is no exception. However, it is worth the time to study.

My advice is to choose one — anyone that strikes your imagination — and start using it. Don't worry about getting it 100% the first time, it probably won't be worse than what you have now, which is one inappropriate key pressed from oblivion.

Play with him. Scan files in a separate workspace and hack things, knowing that it does not matter; You can always return it. Learn how to use the new tool with some GUIs (I really like "svn diff --diff-cmd = kdiff3"). Go to the point where you know how to enter and exit, thing tags, branches and merges. Then show your employees.

Personally, I love svn, but I did not choose it; he chose me.

Answer 6

I don’t know if there is something similar for php, etc., but an interesting resource here is “Brownfield Application Development in .NET” . In many ways, only .NET is used for examples; most of the book is really about politics in the same way you mention:

• how to enter source control
• how to introduce unit testing
• how to introduce continuous integration
• etc.

and all the problems / considerations that come with them.

Partially refers to code; but also related to the "human" factor; colleagues, managers, etc. I highly recommend it; but you can decide that the .NET background is not suitable for you (this is suitable for me; -p).

Answer 7

You can look here: git-for-beginners-the-definitive-practical-guide

This is a distributed version control system that currently has good support for Windows with Git on Windows and a shell extension with TortoiseGit

Answer 8

Adding to other answers:

If the project that you want to install under version control had some releases, and if these versions are available, for example, as tarfiles (for example, project-0.1.tar.gz , project-0.2.tar.gz , project-0.3.tar.gz , ...), you might want to consider importing these versions into your selected version control system. Git has import-tars.perl and import-zips.py in the contrib/fast-import/ directory and writing support for other files in other programming languages ​​for git fast-import should be easy.

Sidenote: My preferred Git version control system.

See also: Good reference or book on the basics and theory of version control .

Answer 9

Wow, everyone just upgrades their favorite version control utility.

OK, to answer your question, how do you place a project under version control?

It’s not so difficult as soon as you choose the version control utility (be it git, svn, hg, bzr .. whatever), usually there is a command or two to initialize the repository, and then add all the relevant files to it.

For example, in git, it could be something like:

 $git init $git add --all $git commit -m"First commit" 

Now, about choosing a version control utility, this is a tricky question and depends a lot on what you want. Perhaps you should take a look at this question:

The popularity of Git / Mercurial / Bazaar against which it is recommended

The only tools you should choose are:

• git
• svn (Subversion)
• hg (Merculiar)
• bzr (Bazaar)
• mtn (monotonous)

Everything else is old or commercial.

svn follows the client server model; There is a central repository. If you are a team of one person, the only thing that means to you is that you need to configure the server and make sure that it starts from the computer. Although I heard that you can end the server. A little googling appears this guide for using svn without a server

All other tools follow a distributed model, again, if you are a team of one person, the only thing that means to you is that the server is not configured.

The advantage of svn is that it has been there for some time and has many gui interfaces and better IDE integration.

I can not compare git with hg (merculiar) since I did not use the latter, but git has a unique storage model compared to svn and hg.

bzr is called easier to use, but slower (it is written in python).

I am personally pleased with git, but you have to do your own research; or maybe just pick one and stick with it. As far as I can tell, they are all mature and stable.

Answer 10

I understood the concepts from the pragmatic series: an example of subversion , they also have books on GIT.

Answer 11

I have experience with SourceSafe and SVN.

SourceSafe seems to have problems corrupting its own database, in a team of 5 we repaired db, maybe once a month. It’s easy, but still you don’t have to deal with it. It is also difficult to label the code and use this label for something practical.

SVN is good, it is easy to install on Linux or Windows. Most IDEs have a plugin for it, and if you use Windows, there is an Explorer extension (TortoiseSVN) that allows you to perform all your actions directly from Windows Explorer. There are many SVN tools for each OS, this is very well supported. SVN also integrates with TRAC (Bug Tracking System) and Bugzilla so you can bind your work tickets to code.

I will say that [HOW you use version control is probably the same as if it weren’t more important than which package you use] [2]. Using it simply as a library is a very rudimentary application, but for a team of 1-2 people creating a website or application where you will not support builds and versions, you will be fine.

When it comes to version control, nothing is better than nothing.