How do repos (SVN, GIT) work?

Question

I read SO nearly everyday and mostly there is a thread about source control. I have a few questions. I am going to use SVN as example.

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

2) I am assuming the answer to the first question is "run an update command which tells you", ok so person B finds out that the file they have been working on all morning in changed. When they see the udpated file, it seems like person A has REWRITTEN the file for better performance. What does person B do? Seems like there whole day was a waste of time. Or if they commit their version then its a waste of person A's time?

3) What are branches?

thanks, and if anyone knows a laymen terms pdf or something that explains it that would be awesome.

Answer 1

1) Assuming there is a central repository (which is the case of SVN and CVS, but not necessarily Git, Bazaar, Mercurial, etc.), and person A commits (and then push the commit, which just transfers the diffs and commit messages to the central repository), person B should update it's copy manually.

2) In this case, yes, someone will have their time gone to waste. SCM systems (Source Control Management) can't do anything to cure a team from it's organizational problems. This is of course an extreme case. Most of the time, there will be only minor differences (the definition of minor here is that any specific file should not be completely or partially rewritten) on each commit, and if those modifications don't touch the section person B is working on, the SCM software will be able to combine those commits into one working file.

Another case here is when two people change the same area of the same file (say, a function). When such conflict happens, the SCM sofware will help you choose which changes you'll use, or even let you use both or neither.

3) A branch is a commit history line:

feature->    /R-S-T
master->  A-B-C-D-E-F
bugfix->       \J-K-L-M

Here, feature, master and bugfix are branches, and letters are specific commits. For branch master, the newest commit (the most recent version of each file) is F. On the other way, branch feature's newest commit is T and it includes only commits A and B from branch master. Any changes made in commits C, D, E and F aren't included in that specific branch. It can be rewritten as:

feature-> A-B-R-S-T
master->  A-B-C-D-E-F
bugfix->  A-B-C-J-K-L-M

Now, branches are important to divide the workflow into different compartments, and focus the work on specific parts. Imagine branch master is where the stable code is located, and imagine we're implementing a new feature on branch feature, which is not yet ready for release. Now imagine that the plugin system is changed, and important bugfixes are commited to the master branch, and, because the feature I'm implementing relies on the plugin system, I need to transfer those commits (C through F) to branch feature. To do that you issue a rebase (I'm using Git as guide here) command to you SCM software, so that:

feature->            /R-S-T
master->  A-B-C-D-E-F
bugfix->       \J-K-L-M

So now you've finished all work on branch feature. To transfer commits R, S and T to master, you issue a merge command:

master->  A-B-C-D-E-F-R-S-T
bugfix->       \J-K-L-M

That's the branch basics. There are lots of other cool things you can do to branches. Hope that is not too long and helps :P