Geek Answers Handbook

How do repositories (SVN, GIT) work?

I read SO almost every day, and basically there is a stream about source control. I have a few questions. I am going to use SVN as an example.

1) There is a team (a small, big literal thing). In the morning, everyone checks the code to start working. At noon, Person A commits while Person B is still working on it. What happens when person B commits? how does person B know that there is an updated file?

2) I assume that the answer to the first question is “run the update command that tells you”, well, so that person B finds out that the file that they worked all morning has changed. When they see a duplicate file, it seems that the person has A REWRITTEN file for better performance. What does man B do? It seems that all day was a waste of time. Or if they commit their version, is it a waste of time?

3) What are branches?

thanks, and if anyone knows the terms of ordinary people pdf or something that explains it, that would be awesome.

+6
version-control branch svn
source share
13 answers

1) Assuming that there is a central repository (this is the case of SVN and CVS, but not necessarily Git, Bazaar, Mercurial, etc.), and person A commits (and then pushes a commit, which simply transfers the diff and commit messages to the central repository ), person B must update it manually.

2) In this case, yes, someone will spend their time. SCM systems (Source Control Management) cannot do anything to cure a team of its organizational problems. This, of course, is an extreme case. In most cases, there will be slight differences (the definition of the minor here is that any particular file should not be completely or partially rewritten) for each commit, and if these changes do not affect the section in which person B operates, the SCM software will be able to combine these commits to one working file.

Another case where two people change the same area of ​​the same file (say, a function). When such a conflict occurs, the SCM software will help you choose which changes you will use, or even allow both of them to be used.

3) A branch is a commit history line:

feature-> /RST master-> ABCDEF bugfix-> \JKLM

Here feature , master and bugfix are branches, and letters are specific commits. For the master branch, the newest commit (the latest version of each file) is F On the other hand, the feature newest branch does T and it only includes commits A and B from the master branch. Any changes made to commits C , D , E and F are not included in this branch. It can be rewritten as:

 feature-> ABRST master-> ABCDEF bugfix-> ABCJKLM

Branches are now important for dividing the workflow into different compartments and focusing work on specific parts. Imagine that the master branch is where the stable code is located, and imagine that we are implementing a new function on the feature branch, which is not yet ready for release. Now imagine that the plugin system is changed and important corrections are bound to the master branch, and since the function that I implement depends on the plugin system, I need to pass these commits ( C through F ) to the feature branch. To do this, you issue the rebase command (I use Git here as a guide here) for the SCM software to:

 feature-> /RST master-> ABCDEF bugfix-> \JKLM

So now you are done with the feature branch. To pass the commits R , S and T to master you issue the merge command:

 master-> ABCDEFRST bugfix-> \JKLM

This is the foundation of the industry. There are many other interesting things you can do for branches. Hope this doesn't take too long and helps: P

+5
source share

12)
SVN When B tries to commit, a message appears stating that it does not have the latest version of the code. He will need to do svn update and combine the changes that person A has made with his own. See How to resolve SVN conflicts .

Git . Since you have your own local repository, you are free to make transactions. This is when you push ( git push ) your changes to a remote repository that you must merge. See Resolving Merge Conflicts in GIT

3) Branch Wiki Page

+5
source share

As an added note, if you plan to completely rewrite a file, it is often polite so that team members working on the same functionality know to avoid merging the pain in-tuckus.

+2
source share
  • Person B can check for modifications from SVN. In fact, I'm sure there is some kind of tool to check for changes every few minutes and warn them about them.
  • They bring change together.
  • Basically, when you make changes, you want to accept as your working copy and change it outside of all the other working copies (trunk). So you make a branch. This way, other people can work on the branch if they want, but it’s basically good that they can work in the trunk without worrying about it, and then you merge the branch when you are finished with this violation of changes.
+1
source share

1 and 2 depend on the version control you are using, but there is some kind of merge that needs to be done. And branches are versions of code that have been decoupled from the trunk (main version).

+1
source share
  • Person B knows that there are changes when he starts the update or tries to transfer to the server.
  • This process is called merging. Most systems are very smart and try to integrate for you. However, sometimes conflicts arise, in which case the person is informed and asks to resolve the conflict. This will happen if person A and B change the same line of code in the same file.
+1
source share

I would say do it often. And before each commit, update.

I would recommend reading this document, it very well explains the various possible workflows of centralized and decentralized (better) version control systems: http://wiki.bazaar.canonical.com/Workflows

0
source share

Good for Git, you basically copy the entire project from the "master" branch to your personal branch, where you can change and commit changes to your personal branch, and if you think this is good, you can merge your personal branch with the lead.

0
source share

What I say below is valid for svn, for git or mercury things are slightly different (I would say easier).

1) Person B should update and merge the changes inside his local copy to commit -ing (she can also just check if there are changes). If he simply tries to commit , she will receive a message stating that his local copy of svn is out of date.

2) Person B has some problems, since merging will not be easy (with SVN it will not be automatically managed by SVN, it will be a conflict ) ... if it is really too difficult B will have to think that it will change again.

This problem really has no solution. Some version control system allows some kind of blocking, but causes other problems (the file can remain locked for a long time, and no one except the cabinet can work on it even between goals that merge easily). Just make frequent small changes and speak with other codons (through a real meeting, IRC, email, or any other means) to prevent this from happening.

3) Branching is really useful with a distributed version control system. It exists in svn in a crippled version. It’s just that you make a copy of the current directory of the current repo in another directory, both directories evolve each with its own life cycle (say, one frozen for fixes only, and the other for new functions and evolutions), and at some point you try to merge the changes between two repositories, for example, trying to port bugfix to branches of new functions or backing up some new function of a new branch in the old one.

0
source share

2) At this point, B must combine the changes made by A with his own changes. If they worked on different parts of the code in a file, the source control tool can usually do this automatically. If their changes overlap, this can be a rather odious task, but this rarely happens.

3) A branch is like a copy of the part of the repository on which you can work (commit changes) separately from the main development line - this can be useful for all kinds of purposes, for example. when you have old versions that you want to provide patches without forcing users to upgrade to the current version (most major software projects do this).

0
source share

I want you to read more about tools like SCM. These actions that you doubt are very common in the development environment. Here are my suggestions for SVN and Git books:

Good to read :-)

0
source share

  • In SVN, B learns of a change when B tries to update a copy of it or register it. In GIT, he finds out when he tries to make changes to his local repository or push the changes to the wizard. (Actually, I don't know GIT, so I continue what I know about Mercurial.)

  • In this case, you have problems no matter what you do, and no matter what type of version control you use. The only advantage of blocking VCS is that it will let A or B know that another is working on the program, but this can be done in other ways. Actually, so that everyone knows about the big changes taking place and coordinating from there. In practice, however, this does not happen often. In most cases, if A and B work on a file, their changes will merge easily and correctly.

  • A branch is another “latest version,” so not everyone should work on the same line of code development all the time.

One use of branches is to develop a function or something else that takes a lot of time without messing up the main line with partial commits.

Another is to keep release versions. Instead of sending the latest version to the client (which may not work completely and may contain functions for which the client did not pay) to fix the error, fix the error on the release branch and send it. This is much less damaging to the customer. (Just make sure the bug is fixed on the head version as well.)

0
source share

I cannot recommend enough Eric Sink Source HOWTO . It will give you the answers you are looking for and a good understanding of source management in general.

0
source share

More articles:


All Articles