How do repos (SVN, GIT) work?_问答_开发者_运维开发者技术经验分享

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.

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

1 && 2)
SVN: When B tries to commit, there will be an error saying that he does not have the latest version of the code. He'll need to do an svn update and merge the changes that person A has done with his own. See How to Resolve SVN conflicts.

GIT: Because you have your own local repository, you can commit freely. It's when you push (git push) your changes to the remote repository that you have to merge. See Resolving Merge Conflicts in GIT

3) Branching Wiki Page

As an added note, if you're planning on completely rewriting a file, it's often polite to let team members working on the same functionality know to avoid pain-in-the-tuckus merges.

Person B can do the Check For Modifications thing from SVN. I'm actually pretty sure there is some tool out there to check for modifications every few minutes and alert you of them.
They merge the changes together.
Basically, when you are making a breaking change, you want to take how your working copy is and change it outside of everyone else's working copy(trunk). So you make a branch. This way, other people can work on the branch if they want but mainly the good thing is they can work in trunk without worrying about it, and then you merge the branch in when your done with that breaking change

1 & 2 depend on the source control that you use, but there is some kind of merge that must be performed. And branches are versions of the code that have been forked from the trunk (main version).

Person B knows that there is a change when he runs an update or attempts to commit to the server.
This process is called merge. Most systems are very smart and attempt to merge for you. However, sometimes there are conflicts and in that case the human is informed and asked to resolve the conflict. This would happen is person A and B both modify the same line of code in the same file.

I'd say, commit often. And before each commit, update.

I'd recommend reading this document, it explains pretty well the different possible workflows of centralized and decentralized (way better) version control systems: http://wiki.bazaar.canonical.com/Workflows

Well for Git, you basically copy the entire project from the "master" branch into your own personal branch, where you can modify and commit changes to your own personal branch and if you think its good you can merge your personal branch with the master one.

2) At this point, B has to merge the changes A has made with his own changes. If they have worked on different parts of the code in the file, the source control tool can generally do this automatically. If their changes overlap, it can become a pretty odious task, but this happens rarely.

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

I gess you need read more about SCM like tools. This operations you have doubt are very much common in a development enviroment. Here goes my suggestions about SVN and Git books:

Practical Subversion, Second Edition
Pragmatic Version Control: Using Subversion
Version Control with Git: Powerful tools and techniques for collaborative software development
Pro Git
Software Configuration Management Patterns: Effective Teamwork, Practical Integration

Good read :-)

What I say below is valid for svn, for git or mercurial things are slighly different (i would say easier).

1) Person B should update and merge changes within his own local copy before commit-ing (she can also just check if there is changes). If he just tries to commit she will get a message stating that his local svn copy is out of date.

2) Person B is in some trouble as the merge will not be easy (it will not be managed automatically by SVN, it will conflict)... if it's really too difficult B will have to think her changes again.

This problem does not really have a solution. Some versioning system allow some kind of lock but it raise other problems (a file could stay locked for a long time and nobody beside the locker can work on it in between even for chages that would easily merge). Just commit often small changes and speak with other coders (by real meeting, IRC, e-mail or any other mean) to avoid that to happen.

3) Branching is really usefull with distributed version control system. It exists in svn in a maimed version. Merely you make a copy of the current dir of the current repo in another directory, the two directory evolve each with his own life-cycle (say one frozen for bugfixes only and the other for new features and evolutions) and at some point you try to merge changes between the two repos, like trying to port bugfix in new features branch, or backporting some new feature of the new branch in the old one.

In SVN, B will know of A's change when B tries to update his copy or check in. In GIT, he'll find out when he tries to pull changes into his local repository or push his changes to the master. (Actually, I don't know GIT, so I'm going on what I know of Mercurial.)
In a case like that, you've got problems no matter what you do, and no matter what sort of version control you use. The only advantage of locking VCSs is that it will let A or B know that the other is working on the program, but that can be done in other ways. The proper thing to do is to have everybody aware of large changes taking place, and coordinate from there. In practice, though, this does not happen frequently. Most of the time, if A and B are working on a file their changes will merge easily and correctly.
A branch is a different "latest version", so not everybody has to work on the same line of code development all the time.

One use of branches is to develop a feature or something else that will take a long time, without messing up the main line with partial commits.

Another is to maintain release versions. Instead of shipping the customer the latest version (which may not entirely work, and may contain features the customer hasn't paid for) to fix a bug, fix the bug on the release branch and ship that. It's a lot less disruptive to the customer. (Just make sure the bug is fixed on the head version, also.)

I cannot recommend enough Eric Sink's Source Control HOWTO. It will give you the answers you seek and a good understanding of source control in general.