SVN merging

Discussion about everything. New games, 3d math, development tips...
Post Reply
elvman
Posts: 253
Joined: Sun Sep 17, 2006 9:37 am
Location: Riga, Latvia
Contact:

SVN merging

Post by elvman »

Merged from branch 1.4, revisions 1275:1289
Why, and what does this mean?
I have worked with version control systems for a long time, but have never had anything to do with this kind of actions.
MasterGod
Posts: 2061
Joined: Fri May 25, 2007 8:06 pm
Location: Israel
Contact:

Post by MasterGod »

As much as I understand it means the the code/files that were changed in the branch of 1.4 revision 1275 were merged with the code/files of the trunk - revision 1289.

Edit:
Lets say this code is the same for both directories:

Code: Select all

func()
{

}
Now in branch you added this:

Code: Select all

func()
{
	int a;
}
trunk added this:

Code: Select all

func()
{
	int b;
}
merge == :

Code: Select all

func()
{
	int a;
	int b;
}
Image
Dev State: Abandoned (For now..)
Requirements Analysis Doc: ~87%
UML: ~0.5%
alexionne
Posts: 55
Joined: Fri Jun 22, 2007 9:55 am
Location: Novi Sad, Serbia

Post by alexionne »

Funny, MasterGod, but you have chosen example which will generate merging conflict :-) Because, it is equally possible that you merge it as

Code: Select all

func()
{
   int b;
   int a;
}
elvman: I'll try to explain branch merging little more on two examples:


Examples #1: Suppose that you have team of several programmers. Now, each one of them works on their part of software (rendering, physics, AI system, ...). Each of them wants to have his/her code version controlled independent of others. What they do is that they create separate branch for their own use. Now, whenever some of them finishes part of software, (s)he merges changes from his branch into the main software branch.


Examples #2:

1. Let's say you're developing software, and at some revision you build version 1.4 of software.

2. After that point you want to continue working on your software but you also want to leave room for bugfixing of version 1.4. So, what do you do? You make a branch for that bugfixing, and continue your work in the main branch.

3. Now, you are able to further develop your software, going to version 1.5, and those changes will not affect version 1.4 because it is in another branch. And if you make some bugfix in version 1.4 it will not affect version 1.5.

4. At some moment later, you want to finalize your work on version 1.5, but you also want that this version include all bugfixes of version 1.4. What you do is that you merge those two branches so that you get final version 1.5 of your software.

Note: Any conformance with present Irrlicht version is just a coincidence. :-)
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Yeah, that's basically it. Just want to say that we are developing under trunk (for a version 1.5) and under branches/releases/1.4 for an upcoming 1.4.1 release. Hence, only really important changes and some minor bug fixes go into the 1.4 branch. Instead of copying these changes manually, I merge the branch every 5-10 days into trunk. In order to remember what was merged when, I add the revisions merged. So x:y means all changes between revision x and revision y (including that one) are copied to trunk.
Post Reply