Work with SVN branches
Before you start using branches at all, and even if you don’t think to use them, you need to read this Holy Talmud .
After you have read an article about branches in svnbook, you already understand why branches are needed, how to work with them, and in what cases they need to be used. Basically, after this, what is written under the cut you probably no longer need. But if you were too lazy to read, then the text below may be of interest to you, and you still read the documentation article. Or maybe it will just help you to better understand what you have just read in the svnbook.
What is all this for?
Suppose you have a task that takes more than one day to complete. The policy of frequent commits assumes that we commit more often than once a day. This allows us to receive changes more often and avoid conflicts. If there are not many changes in revision, then the probability of conflicts decreases. We also insure against force majeure, if suddenly we get a gfk - we will not lose a week's work.
')
But sometimes the task is long, and we cannot commit somewhere in the middle, because the unfinished task recorded in the main code may interfere with other developers in their work. But it will not commit a few days too. Secondly, it may be necessary to upload the code to the production. If we commit an unfinished task to the main branch, it will end up in production, which is not kosher. To do this, there are branches. They allow us to commit at any time convenient for us, without disturbing everyone else. Also branches allow you to work on several tasks in parallel, without mixing them.
What is a branch?
This is just a copy of the svn directory. More precisely, the so-called "light copy", containing only the changes. The same files are not copied. The branch has a common history until its creation with the main branch. In the general case, there can be any number of branches, and each of them can branch. But in the standard project it is customary to have three permanent branches:
* trunk - the main line of development. Here the current code will be up to date, small tasks and bug fixes will be performed here.
* branches - a branch for developers. gsuto branches in other branches. It is in it that you will create your own branches.
* tags - tag line. There are all sorts of labels that mark significant milestones in the development of projects, in other words, its stable and not very versions. We need it in order to always be able to return to some version, for example, to see "why this crap worked before and then stopped, bitch"
Programmers are responsible for what
* Create a branch when it is necessary for the stable existence of the project. In general, if you feel that the task will last more than a couple of days (and sometimes a day), and all this time you will not be able to safely commit at least a couple of times a day, you need a branch.
* Keep your branch up to date - that is, you need to get rid of panic fear of the merge team as early as possible, and merge no less than commit. Otherwise, conflicts when merging a branch with a trunk cannot be avoided.
* Delete the branch after the completion of the task . Developer branches are temporary branches, so they should be deleted when the task is completed. In a pinch, they can live a few more days, for the confidence that there are no big mistakes in the task. Then the branch will not need anyone, it can be deleted. Anyway, after a while, it will go so far away from the main line of development that no merge can return to it anymore.
How to work with branches
Creating a new branch is easy. As follows from the Talmud, this is done by the copy command. Suppose we are developing a project - BUMP (Big Afigenny Mega Project). For our case, you need to run this command:
To switch to a new branch:
s
In order to check which branch you are in now
Switching to a new branch, you can make edits, commit, and no one else will notice anything. But we must remember that the switch command is very similar to the update command, so if you switch from one branch to another, you can get conflicts if there were edits in the same file. That is why it is necessary to merge changes from the main branch more often.
Copy changes between branches
In order to keep your branch up to date, you need to periodically copy changes from the main branch. This is necessary in order to avoid conflicts when merging branches or when switching to the main branch. Therefore, merzhitsya need more often, at least once or twice a day. You can take as a rule: merzhitsya before each commit. Komanada merge is probably the most difficult of the svn commands. And the thing is that svn does not remember about your previous merge (up to version 1.5). And if you do not remember, it means you risk to copy to yourself the changes that you already have after the previous merge. But this drawback is easy to get around. After each copying of changes into your working copy, you need to commit them to your branch. In the comments, specify the range of revisions included in your current account. That is, for example: “merged from trunk r1234: 1256”. This comment will serve as a reminder for you, and at any time you will be able to see when you last merged and what revision is the last. Such comments must be included, otherwise there will be big problems and misunderstandings. And further. In order to be sure that everything is successful, you can first, before the actual copying, make a test. To do this, use the --dry-run option which only shows the output without making changes to the working copy.
So, see the changes from the trunk by using this command:
We get, for example, the following conclusion:
This means that in the r4107 revision 3 files have changed. Great, all right, copy the changes
And we commit to:
The number 4108 is the current revision number. Get it easy. It is enough to execute the svn up command.
Notice that the number 4106, in this case, is a revision of the creation of our branch. When you first merzhitsya, you will need to know the number of this audit. It's easy, just run the command.
Then you no longer need this number. You can find out the number of the required revision from your own comment. Thus, when you are merging the next time you need to find out the revision number of the last merge. For example, in Linux, I do this:
Thus, in order to sherzhit again from the trunk to run the command
Completing the task
If the work on the task is completed, you need
* Merge your changes into trunk
* Remove your thread so that it does not interfere
We merge in a trunk the same merge team. To do this, find out the revision of the branch creation, and switch to the trunk.
After that, copy the changes from your branch
If everything went well, there are no conflicts and you don’t need to finish anything, commit changes to the main branch, and you can delete your branch now. It does not differ at all from a trunk, and if necessary we can always create another branch. Yes, and it is worth remembering that our branch is of course not physically removed, it is just removed from HEAD, but in early revisions we can always find it, and if necessary, restore it. So be bold:
By the way, deleting a branch after merging a task into a trunk is not strictly necessary. Deleting a branch is necessary when completing a task, and merging into a trunk does not mean that the task is completely completed. Theoretically, you can merge your changes (both completely and partially) several times during the work on a task, for example, if the task is divided into stages, each of which is complete and workable. Or, for example, the changes that you made are necessary (or may be useful) to other developers, but do not interfere with the work of the entire application (new lib, or additions to the interface of existing libs and classes). In general, the decision about the change of the trunk should be made by the programmer (or group) - the owner of the branch. Which of course does not exclude the option of someone to consult if there is any doubt.
In principle, it is desirable to try to avoid any significant discrepancies between the trunk and other branches, unless, of course, this does not interfere with the project.
Conclusion
This article contains only a small part of information about working with branches. It can serve as a reminder, but not as a tutorial. Therefore, it is strongly recommended to read the corresponding svnbook section. It contains a lot of information that did not fall into this opus, but are necessary for understanding how to work with branches.
After you have read an article about branches in svnbook, you already understand why branches are needed, how to work with them, and in what cases they need to be used. Basically, after this, what is written under the cut you probably no longer need. But if you were too lazy to read, then the text below may be of interest to you, and you still read the documentation article. Or maybe it will just help you to better understand what you have just read in the svnbook.
What is all this for?
Suppose you have a task that takes more than one day to complete. The policy of frequent commits assumes that we commit more often than once a day. This allows us to receive changes more often and avoid conflicts. If there are not many changes in revision, then the probability of conflicts decreases. We also insure against force majeure, if suddenly we get a gfk - we will not lose a week's work.
')
But sometimes the task is long, and we cannot commit somewhere in the middle, because the unfinished task recorded in the main code may interfere with other developers in their work. But it will not commit a few days too. Secondly, it may be necessary to upload the code to the production. If we commit an unfinished task to the main branch, it will end up in production, which is not kosher. To do this, there are branches. They allow us to commit at any time convenient for us, without disturbing everyone else. Also branches allow you to work on several tasks in parallel, without mixing them.
What is a branch?
This is just a copy of the svn directory. More precisely, the so-called "light copy", containing only the changes. The same files are not copied. The branch has a common history until its creation with the main branch. In the general case, there can be any number of branches, and each of them can branch. But in the standard project it is customary to have three permanent branches:
* trunk - the main line of development. Here the current code will be up to date, small tasks and bug fixes will be performed here.
* branches - a branch for developers. gsuto branches in other branches. It is in it that you will create your own branches.
* tags - tag line. There are all sorts of labels that mark significant milestones in the development of projects, in other words, its stable and not very versions. We need it in order to always be able to return to some version, for example, to see "why this crap worked before and then stopped, bitch"
Programmers are responsible for what
* Create a branch when it is necessary for the stable existence of the project. In general, if you feel that the task will last more than a couple of days (and sometimes a day), and all this time you will not be able to safely commit at least a couple of times a day, you need a branch.
* Keep your branch up to date - that is, you need to get rid of panic fear of the merge team as early as possible, and merge no less than commit. Otherwise, conflicts when merging a branch with a trunk cannot be avoided.
* Delete the branch after the completion of the task . Developer branches are temporary branches, so they should be deleted when the task is completed. In a pinch, they can live a few more days, for the confidence that there are no big mistakes in the task. Then the branch will not need anyone, it can be deleted. Anyway, after a while, it will go so far away from the main line of development that no merge can return to it anymore.
How to work with branches
Creating a new branch is easy. As follows from the Talmud, this is done by the copy command. Suppose we are developing a project - BUMP (Big Afigenny Mega Project). For our case, you need to run this command:
svn copy svn://svnserver/var/bump/trunk svn://svnserver/var/bump/branches/my-branch -m="Creating a private branch of /bump/trunk"
To switch to a new branch:
s
vn switch svn://svnserver/var/bump/branches/my-branch
vn switch svn://svnserver/var/bump/branches/my-branch
In order to check which branch you are in now
svn infoSwitching to a new branch, you can make edits, commit, and no one else will notice anything. But we must remember that the switch command is very similar to the update command, so if you switch from one branch to another, you can get conflicts if there were edits in the same file. That is why it is necessary to merge changes from the main branch more often.
Copy changes between branches
In order to keep your branch up to date, you need to periodically copy changes from the main branch. This is necessary in order to avoid conflicts when merging branches or when switching to the main branch. Therefore, merzhitsya need more often, at least once or twice a day. You can take as a rule: merzhitsya before each commit. Komanada merge is probably the most difficult of the svn commands. And the thing is that svn does not remember about your previous merge (up to version 1.5). And if you do not remember, it means you risk to copy to yourself the changes that you already have after the previous merge. But this drawback is easy to get around. After each copying of changes into your working copy, you need to commit them to your branch. In the comments, specify the range of revisions included in your current account. That is, for example: “merged from trunk r1234: 1256”. This comment will serve as a reminder for you, and at any time you will be able to see when you last merged and what revision is the last. Such comments must be included, otherwise there will be big problems and misunderstandings. And further. In order to be sure that everything is successful, you can first, before the actual copying, make a test. To do this, use the --dry-run option which only shows the output without making changes to the working copy.
So, see the changes from the trunk by using this command:
svn merge -r4106:HEAD svn://svnserver/var/bump/trunk ./ --dry-runWe get, for example, the following conclusion:
--- Merging r4107 into '.':
U db/queries.txt
U ejb/src/main/java/ru/bump/action/folder/MoveFolderActionLocal.java
U ejb/src/main/java/ru/bump/action/user/UserRegistrationAction.javaThis means that in the r4107 revision 3 files have changed. Great, all right, copy the changes
svn merge -r4106:HEAD svn://svnserver/var/bump/trunk ./
And we commit to:
svn ci -m "merged from trunk r4106:4108"The number 4108 is the current revision number. Get it easy. It is enough to execute the svn up command.
Notice that the number 4106, in this case, is a revision of the creation of our branch. When you first merzhitsya, you will need to know the number of this audit. It's easy, just run the command.
svn log --stop-on-copyThen you no longer need this number. You can find out the number of the required revision from your own comment. Thus, when you are merging the next time you need to find out the revision number of the last merge. For example, in Linux, I do this:
#:~/www/bump$ svn log | grep merged
merged from trunk r4106:4108Thus, in order to sherzhit again from the trunk to run the command
svn merge -r4109:HEAD svn://svnserver/var/bump/trunk ./Completing the task
If the work on the task is completed, you need
* Merge your changes into trunk
* Remove your thread so that it does not interfere
We merge in a trunk the same merge team. To do this, find out the revision of the branch creation, and switch to the trunk.
svn switch svn://svnserver/var/bump/trunkAfter that, copy the changes from your branch
#svn up
At revision 4155
#svn merge svn://svnserver/var/bump/trunk@4155 svn://svnserver/var/bump/branches/my-branch@4155If everything went well, there are no conflicts and you don’t need to finish anything, commit changes to the main branch, and you can delete your branch now. It does not differ at all from a trunk, and if necessary we can always create another branch. Yes, and it is worth remembering that our branch is of course not physically removed, it is just removed from HEAD, but in early revisions we can always find it, and if necessary, restore it. So be bold:
svn delete svn://svnserver/var/bump/branches/my-btanch -m "Removing my-branch branch."By the way, deleting a branch after merging a task into a trunk is not strictly necessary. Deleting a branch is necessary when completing a task, and merging into a trunk does not mean that the task is completely completed. Theoretically, you can merge your changes (both completely and partially) several times during the work on a task, for example, if the task is divided into stages, each of which is complete and workable. Or, for example, the changes that you made are necessary (or may be useful) to other developers, but do not interfere with the work of the entire application (new lib, or additions to the interface of existing libs and classes). In general, the decision about the change of the trunk should be made by the programmer (or group) - the owner of the branch. Which of course does not exclude the option of someone to consult if there is any doubt.
In principle, it is desirable to try to avoid any significant discrepancies between the trunk and other branches, unless, of course, this does not interfere with the project.
Conclusion
This article contains only a small part of information about working with branches. It can serve as a reminder, but not as a tutorial. Therefore, it is strongly recommended to read the corresponding svnbook section. It contains a lot of information that did not fall into this opus, but are necessary for understanding how to work with branches.
Source: https://habr.com/ru/post/45203/
All Articles