merging beta 2 code into my beta 1 code base?

#1 if you aren't using it yet, give WinMerge a go

#2 Also, I wonder if it would be better to connect to GG's svn repository (read-only) and just (svn update) from there every day instead of every few months...

...

Is WinMerge better than subversion/svn merge?

I just wondered if there'd be a doc or something on this, since it seems like it would be annoying to keep doing if it's not mostly automated. Or maybe just a process-and-tool I need to learn

#3 Usually you would keep the "vender" version of the engine in your svn as well. Like, repo:vender/torque3d/trunk, with tags for beta1, beta2, etc..

Then you can merge the beta2 changes into beta1 using something like a folder compare in beyond compare. Then commit that and create a new tag for beta2... Now you have both of those in svn you can have svn merge the differences into your project.

#4 And yeah, it is a lot of work...

Actually, its probably simpler to instead merge your project into a fresh install of t3d beta2. It's not like you will be going back... so making a svn tag and everything for it is probably unnecessary work.

#5 I wonder which is better...

A) Merge (the new beta 2 source) into (our beta 1, which includes our changes), or

B) do a diff between (the original beta 1) and (our beta 1, which includes our changes). Then, svn apply that diff/patch to (the new beta 2 source)

hmmm...

#6 I guess I also wonder if B even works...

#7 Did a quick diff and about 260 changed files and 60-70 new/moved files. Probably want to patch in your changes instead of the other way around.

#8 Gah, I think moved files makes it sound more complicated. Especially if we don't have the file move (or god forbid rename) logs...

I wonder if (svn merge) or (WinMerge) or (folder compare) or (something else?) is the way to go...

Maybe I do:
1) svn diff/patch between (rev_base, meaning original Torque 3D beta 1) and (rev_current, meaning my top of tree)
2) apply the diff/patch to a Torque 3D beta 2 copy
3) create an entirely new svn r1, using "2)"

Hmmmm, this doesn't sound very ideal...

#9 I really wonder if my step 2 is going to work when there were file moves, and no logs specifying what files were moved/renamed from where to where :-/

#10 There weren't that many renames/moves, so I doubt you'll have many conflicts. If so, do those files one at a time...

#11 @James and Joshua:

I don't think WinMerge or beyond compare can apply a diff/patch. And subversion won't seem to let me apply the diff/patch to my Torque 3D beta 2 folder, because its not in revision control yet. And unix/cygwin (patch -p < myDiff.diff), I'm not sure whether I want to use that since it's just a command-line tool that is hard to look at the changes in detail (like you can do with TortoiseSVN GUI).

So maybe I have to do this:

1) svn diff, between (rev_base, meaning original Torque 3D beta 1) and (rev_current, meaning my top of tree)
2) create an entirely new (repository or branch or folder) from Torque 3D beta 2 unmodified (meaning it doesn't include my changes)
3) apply my diff from "1)" to this new folder
4) optionally, I can delete (Torque 3D beta 1) since I'm done with it

#12 Don't make it so complicated. Open winMerge and bring up both code directories. Organize by Beta 1 file changed date. Just go through and left->right your changes. Go line by line, don't just copy files over. Obviously you're copying from Beta 1 (with your changes) to a fresh copy of Beta 2.

I always tag my code alterations with a unique comment code so I can find my changes vs. differences between versions of the engine.

Porting from Beta 1 to Beta 2 earlier today took about 15-20 minutes. I have a pretty heavily-modified codebase going back to TGE 1.3.

I don't recommend any automatic processes, like patching, etc.

#13 Hmm... Is it generally a good idea to wrap every single line of code change I make, both C++ and TorqueScript, with comments? Ie, "tag my cold alterations"?

For example:
// BEGIN: Code Section, not from Torque trunk; My foobar Game
[the code goes here]
if foo == bar:
{
cout << "hello world"
}
// END : Code Section, not from Torque trunk; My foobar Game

PS: thank you for the additional help Henry (and James and Joshua)

#14 Btw, I mean for both C++ files and TorqueScript files, and maybe even other text files like txt or shaders. And for both new files, and for modifications of existing files (C++ and TorqueScript etc).

#15 I mark all my code bits with a //[my 3 char marker] followed with comments about what this code change do. Then whenever i need to change something its easy to search down and find. Also when doing code DIF I just look for my 3 character markers, and move them over. Its a trick i learned from real programmers when i worked with PRO teams.

#16 If you do a lot of merging across versions it might be worthwhile, i leave all the tags in for resources i implement mostly because i get lazy and dont read all the code to understand what its doing, and it also highlights areas where multiple resources may conflict AFX vs Simple melee for example.

Depending which merge tool you use (i use araxis standard version) the highlighting is very helpful and removes the need for some of the tags.

just as a side note, ive never ever been comfortable with merging to and from SVN or any other repository, instead i prefer to have multiple local copies and then commit the final merge result (ive never used svn in a large group scenario however.

edit: lol my //[3 char marker] comes in two flavours // MJC (my initials) or // umm (faster to type than "wtf does this do")

:)

#17 I ALWAYS comment any changes to the base code with unique tags,
and comment why and what the additions are for, also what I am trying to
accomplish with them.

I can tell you it makes:
1) understanding your code much easier for any new programmer
2) my brain seems to have a limit to what it can store, and reminds me what the
new code is for and why.

But everyone has their own processes I guess :)

#18 Thank you all for the great feedback and discussion.

Here's a more detailed question. Do you think it's better to do A or B?

A: just wrap the code with comment tags
// BEGIN: Code Section, not from Torque trunk; My foobar Game
[the code goes here]
if foo == bar:
{
cout << "hello world"
}
// END : Code Section, not from Torque trunk; My foobar Game

B: put a comment on every single line, even if the line already has a comment
[the code goes here]
if foo == bar: //[foobar]
{
cout << "hello world"; // this is a print statement //[foobar]
}

Maybe B is more thorough, but is it too much? I mean, kind of annoying?

...

Or maybe it's good to generally use A. Unless your code change is mixed in with GG code, in which case you would do:

GG's original code:
int a = 10;
if foo = bar:
{
a += 5;
}
cout << "A is: " << a;

Our modified code:
// BEGIN: Code Section, not from Torque trunk; My foobar Game
int a = 10;
int b = 5; //[foobar]
if foo = bar:
{
//a += 5; //[GG code]
a += b; //[foobar]
a *= b; //[foobar]
a -= 20; //[foobar]
}
//cout << "A is: " << a; //[GG code]
cout << "A has an awesome value: " << b << ", and so does B: " << b;
// END : Code Section, not from Torque trunk; My foobar Game

...

Thoughts?

#19 Your best bet in all these cases is....

1. Use SVN.
2. Use a vendor branch.
3. Avoid changing core Torque code when possible.
4. When you do change core Torque code be sure to well comment it as your own change. This includes adding a commit comment.

... if you do these things its makes it easier to deal with changing T3D code, but it can still occasionally come down to manual merges by hand.

#20 Interesting. I think this svn vendor branch thing sounds significantly different from the previous suggestions to (comment flag your code changes, and then winmerge/etc old-torque_beta_1-with-your-changes into new torque_beta_2)