Merge your changes with V12 Update
by AIDan · in Torque Game Engine · 09/19/2001 (10:28 pm) · 10 replies
Hi
This topic is about how to merge changes you have made with changes applied to the newest V12 version, you are going to get via CVS.
One idea is to create a patch of your changes, so you can merge them into the new version.
Good idea, but what about functions you have moved into other files or when files are added or removed??
So the first thing would be to find all changes from the version you are using and the new version.
There are programs which allow to merge files without loosing any information, but I have never used such a program. Maybe someone can tell me.
When you got a list of all functions, gui's and files which were added, moved or removed, you had to check your patch whether all changes would be applied correctly.
That should work.
- Create a patch from the old V12 to your current version
- Check changes made within the new version
- Overwork your patch, so all changes will be applied correctly
- Patch new version
Another fact is, that everybody has to do this, so it would be much easier, if Garagegames would create this patch. Also you cannot do this all day because of ONE file has changed.
It would be very helpful, if Garagegames could release patches in time.
- Create a patch from the old V12 to current version
- Add list of functions, gui's and files which are added, moved or removed.
I would prefer this solution, not because of Garagegames does all the work, but because of everybody has the "same" version, so you don't get problems with this. There are no missing files or changes due to different versions. You cannot patch your code everyday.
greetings
Daniel
This topic is about how to merge changes you have made with changes applied to the newest V12 version, you are going to get via CVS.
One idea is to create a patch of your changes, so you can merge them into the new version.
Good idea, but what about functions you have moved into other files or when files are added or removed??
So the first thing would be to find all changes from the version you are using and the new version.
There are programs which allow to merge files without loosing any information, but I have never used such a program. Maybe someone can tell me.
When you got a list of all functions, gui's and files which were added, moved or removed, you had to check your patch whether all changes would be applied correctly.
That should work.
- Create a patch from the old V12 to your current version
- Check changes made within the new version
- Overwork your patch, so all changes will be applied correctly
- Patch new version
Another fact is, that everybody has to do this, so it would be much easier, if Garagegames would create this patch. Also you cannot do this all day because of ONE file has changed.
It would be very helpful, if Garagegames could release patches in time.
- Create a patch from the old V12 to current version
- Add list of functions, gui's and files which are added, moved or removed.
I would prefer this solution, not because of Garagegames does all the work, but because of everybody has the "same" version, so you don't get problems with this. There are no missing files or changes due to different versions. You cannot patch your code everyday.
greetings
Daniel
About the author
#3
The problem really occures when you want to run your own CVS repository for your game so that you can coordinate with others on your project. This can also be handled with CVS, but it's a little more cumbersome. You'll have to make a branch on your CVS, checkin the latest SDK into that branch, then merge that branch with your main trunk development. I think there are other ways to do this using some CVS vender branchs, but I'm having looked into it much, and I think it results in basically the same thing.
In all cases, conflicts will have to be corrected manually. Anybody actually been through this process using CVS?
09/20/2001 (7:09 am)
If you do a checkout from CVS, then change your local copy, and then update from CVS, it will merge in the latest CVS changes with your code. This part should work fine once everyone is using CVS.The problem really occures when you want to run your own CVS repository for your game so that you can coordinate with others on your project. This can also be handled with CVS, but it's a little more cumbersome. You'll have to make a branch on your CVS, checkin the latest SDK into that branch, then merge that branch with your main trunk development. I think there are other ways to do this using some CVS vender branchs, but I'm having looked into it much, and I think it results in basically the same thing.
In all cases, conflicts will have to be corrected manually. Anybody actually been through this process using CVS?
#4
09/20/2001 (7:15 am)
On the patch thing... thinking about this one. Patches would mean you wouldn't have to install CVS, but would actually be more work for us, as we'd have to generate patches from the last patch, etc., in order, for all interim releases. They would have to be applied in order as well, essentially what CVS would handle automatically.
#5
But its an issue if you need to keep your own seperate CVS repository.
I was thinking it might be possible to use CVS to get the v12 as it changes, and have this then checked into sourcesafe :) so basically I'd checkout from sourcesafe (which quite happily runs on the local machine), do a get from CVS into the same dir (merging the local and remote CVS copy) and then do a check back into sourcesafe :))
Ok. mad, but it just might work (I dont need to give anyone else access to sourcesafe, I just want to use it for keeping a log of my changes).
Phil.
09/20/2001 (7:03 pm)
I was thinking along the same lines last night. CVS is the most obvious route, in that you can use the merge of CVS to keep everything together.But its an issue if you need to keep your own seperate CVS repository.
I was thinking it might be possible to use CVS to get the v12 as it changes, and have this then checked into sourcesafe :) so basically I'd checkout from sourcesafe (which quite happily runs on the local machine), do a get from CVS into the same dir (merging the local and remote CVS copy) and then do a check back into sourcesafe :))
Ok. mad, but it just might work (I dont need to give anyone else access to sourcesafe, I just want to use it for keeping a log of my changes).
Phil.
#6
I don't see anything about the CVS being up yet. Did I miss something?
09/21/2001 (9:14 am)
I've been out of town all week, and I read through all the posts since I've been gone.I don't see anything about the CVS being up yet. Did I miss something?
#7
09/21/2001 (12:32 pm)
No, not up yet, Ricks still putting the final touches on the machine. He's also taking the opportunity to mirror our main database on this second server, so that's complicating the setup somewhat. 
#9
Also are you planning to include the scripts in the CVS or just the code from the engine? I have been rewriting the editors to make them more compatible with internationalization requirements, but not everyone would necessarily like to see the GUI for the system change to look more like something from Lightwave. (Long narrow buttons that allow you to have the German and French names for buttons - typically longer than the equivalent English button)
09/28/2001 (11:10 pm)
If I set up my own CVS I should be able to treat your changes as input from another member of my team. Where I see a big problem is sending you changes. Someone on your end will need to check out each change to see if it works and more importantly is it something you want to add. When Genesis3D/Jet3D went to CVS one of the problems was people who "fixed" a bug so that it favored the kind of game they were making. In some cases it broke code all over the rest of the CVS - code they had removed because it didn't apply to their game. I would suggest you think about making the downloads one way - from you to us. Then make a submission process where we can send you stuff. It will be slower, and people will grouse a bit that their cool offering didn't get in right away, but people won't be downloading broken code.Also are you planning to include the scripts in the CVS or just the code from the engine? I have been rewriting the editors to make them more compatible with internationalization requirements, but not everyone would necessarily like to see the GUI for the system change to look more like something from Lightwave. (Long narrow buttons that allow you to have the German and French names for buttons - typically longer than the equivalent English button)
#10
So it sounds like the Genesis CVS was Read/Write -- that is really scary.
The CVS will include code, scripts and art -- no binary executables, dlls.
--Rick
09/29/2001 (2:04 am)
The CVS will be read only. Fixes/upgrades can be sent to GarageGames as a patch. We will go over each fix/patch and determine it's correctness and/or suitability. Virtually all successful open source projects are managed like this -- It is a little extra work for the maintainers but it is the only way to keep the code base stable, lean and on course.So it sounds like the Genesis CVS was Read/Write -- that is really scary.
The CVS will include code, scripts and art -- no binary executables, dlls.
--Rick
Torque 3D Owner Frank Bignone
Darkhand Studio