Theory (and terminology) of source control

Question

I tried to use the source control for several projects, but still do not understand. For these projects, we used TortoiseSVN and had only one line of fixes. (There is no trunk, branch, or any of them.) If there is a recommended way to configure version control systems, what are they? What are the reasons and advantages for creating it? What are the differences between a centralized and distributed source management system?

Answer 1

I recommend checking the following: Eric Sink:

http://www.ericsink.com/scm/source_control.html

Having some kind of version control system in place is probably the most important tool a programmer has to analyze code changes and understand who did what to whom. Even for single-person projects, it is invaluable to be able to distinguish between the current code and the previous known working version in order to understand what could have happened incorrectly due to changes.

Answer 2

Think of managing the source as a giant Undo button for your source code. Each time you register, you add a point to which you can roll back. Even if you do not use branching / merging, this function in itself can be very valuable.

In addition, having one “authoritative” version of the source control makes it much easier to back up.

Centralized and distributed ... the difference is really that in a distributed one there is not necessarily one “authoritative” version of the initial control, although in practice people usually still have the main tree.

The big advantage for distributed source control is twofold:

• When you use a distributed control source, you have a complete source tree on your local computer. You can commit, create branches and work to a large extent, as if you were alone, and then when you are ready to undo your changes, you can push them from your computer to the master copy. If you work a lot offline, this can be a huge advantage.

• You do not need to ask anyone to become a source distributor. If person A starts a project, but people B and C want to make changes and exchange these changes with each other, it becomes much easier with distributed source control.

Answer 3

Here are two articles that are very helpful in understanding the basics. In addition to selling Sink, an excellent version control product called Vault is free for single users (I have no affiliation with this company).

http://www.ericsink.com/scm/source_control.html

http://betterexplained.com/articles/a-visual-guide-to-version-control/

Storage information at www.vault.com.

Answer 4

Even if you do not enter a branch, it may be useful for you to use tags to mark releases.

Imagine that you introduced a new version of your software yesterday and started making major changes for the next version. The user encourages you to report a serious error yesterday. You cannot just fix this and copy the changes from your development branch, because the changes you just made are unstable.

If you marked a release, you can check its working copy and use it to fix the error.

Then you can create a branch in the tag and check for bug fixes. This way you can fix more bugs in this version while you keep updating the trunk. You can also combine these corrections in the body so that they are present in the next version.

Answer 5

A common standard for configuring Subversion is to have three folders under the root of your repository: trunk, branches, and tags. In the folder with the chest is the current "main" line of development. For many stores and situations, this is all they ever use ... only one working code repository.

The tag folder takes it one step further and allows you to "check" your code at specific points in time. For example, when you release a new assembly, and sometimes even when you simply create a new assembly, you “put” a copy in this folder. It just lets you know exactly what your code looked like at that point in time.

The branches folder contains various branches that may be needed in special situations. Sometimes a branch is a place to work on an experimental function or functions that can take a long time to become stable (so you don’t want to enter them in your main line yet). In other cases, an affiliate may be a “production” copy of your code that can be edited and expanded independently of the main line of code that contains changes intended for a future version.

In any case, this is just one aspect of setting up your system, but I think it’s important to think about this structure.