SVN and current codebase. Cleanup?

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

SVN and current codebase. Cleanup?

Post by pheonixstorm »

One of the problems with the current svn codebase is this. Where is the stable .5.0 branch?

If you do a view you get 3 choices - branches, tag, and trunk.

Under branches we have a lot of choices and only two subs that look like they hold the vs source. 4_4 and 2_2 There are also two others I found that also have source but don't have the look of a stable, a fork maybe but not a stable.. Ogre and Privateer.

Under tags.. oh wait here is the 0.5.0 stable! And lets not forget about a hundred other directories with full source commits.

So, we have several serious problems. Those doing an svn checkout will have not idea where to start on the stable branch unless there is a post I havent looked for in the forums... There should be a link to the stable svn as well as the latest dev package.

Now, on to the main data section.. We need to make sure there is a 2 datas for the main trunk, the first will be the main for a working dev release while the other will hold ONLY the updated changes waiting for a new compile under win, linux, etc. Everyone can merge the two on their own machines until we get it to compile for ewveryone the merge the 2 datas for a compiled dev build.

I wonder just how organized the original devs were when they started this project.... too much of the code, data, and svn seems to be really haphazard.

Just a few thoughts from my end... ignore, flame, cheer, grump... Just want to see VS get a better look to it than it has now on the backend

BTW the linux builds have about 20k downloads each install while the win32 install has about 123k downloads. Windows might now be the dev platform of choice but for a compiled exe it seems to be the most used, not considering the mods such as Privateer PU and GG that use the engine (only two I can remember).
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: SVN and current codebase. Cleanup?

Post by charlieg »

Yeah, that is a bit poor. Tagging is pretty fundamental.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: SVN and current codebase. Cleanup?

Post by safemode »

I dont think you understand how svn works.

branches is for any type of copy of the main trunk repositories not meant for general consumption by everyone else. These can be more thought of as public personal code repositories. Ways of other people working with you on something outside of trunk so that intermediary work does not effect other people's work. Big stuff goes here first before being merged to head.

There are going to be a lot of branches, that's normal. Users need not apply here.

tags is going to be full of stuff. That's the idea. You cannot delete tags. Every milestone, minor revision, huge merge and release should get tagged. Tags are for developer's benefit, so that they can easily go back to a specific event in in the development model to see when something was altered, or to roll up a pkg. Users need not apply here either. If a user is looking for a specific release, they should be looking in the files section at sourceforge, not the SVN. You can commit to tags I believe so that one may maintain bug fixes to a major release that dont exist in the HEAD anymore. Like say if we wanted to fix something in 0.5.x but have already released a 0.6.x and for whatever reason some mod continues to use 0.5.x


Trunk is for main development. This gets tagged, branched, and this is what gets initially pulled by developers looking to contribute. In VS, we try to keep trunk always working, but it is not a running stable version.


A lot of what you say you want is already there. /tags holds your releases, that can be pkged up and sent off, /branches holds your majorly unstable commits that you can do without worrying about breaking the codebase and trunk is for general developer consumption. Dont bother thinking of SVN as a place for regular users, it's not. It's use by regular users with VS is a symptom of our release timetable. Fixing the release rate is the correct action to take.
Ed Sweetman endorses this message.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: SVN and current codebase. Cleanup?

Post by charlieg »

Whoops, either I misread what phoenixstorm said or he has edited his post since I replied.

Release -> tag. (i.e. I understand how SVN works! ;))

So there is a 0.5.0 tag. Good! :roll:
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: SVN and current codebase. Cleanup?

Post by safemode »

on the topic of codebase cleanup:

I am currently in the process of code scrubbing. This is an almost infinite pass process, but for now i'm focussing on squashing all the latest gcc warnings and implementing a multi-level debug function that lets python and c++ output using the same backend, so that a single argument and/or config directive controls how much gets dumped to the console during runtime ... Minor things really, but tedius (at least the first part) and necessary (first part anyway).

I work about 80 hours a week though, and this past couple weeks the other night manager where i work decided to pass out and goto the hospital so i had to work on my days off to fill in for that job. So i've been unable to complete some stuff i've been meaning to do. hence the two week span of no svn activity.

I stopped my work on physics and collision to focus on cleanup tasks and basically polishing the code a bit so we can prepare for a release, but we have a lot to do yet before that's going to happen. We have cleanups that are necessary, cleanups that are "should do's" and cleanups that require too many changes to be considered this close to wanting to release something and would just push the release much further away (it's extremely difficult to resist formatting cleanups, but it's not the time for those). We have documentation that needs to be updated. All this busywork needs to be done prior to a release, and understandably, nobody really wants to stop what they're doing and do it.

But i may have to stop cleanups to start work on what will become the means for incremental releases. This is an absolute necessity to allow rapid releases of /data and to finally solve many of the problems associated with such long release cycles that we've had.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: SVN and current codebase. Cleanup?

Post by chuck_starchaser »

I mentioned before about Lint C++; it's comercial, but an incredible tool; a real labor of love; but where i once offered to buy it for vs; nowadays I'm broke.
But i continue to recommend it.
Why are employers so stupid, I wonder? They hire too many people, then they fire too many people, then expect too much overtime of the few left...
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: SVN and current codebase. Cleanup?

Post by charlieg »

phoenixstorm: I understand that SVN is not pretty to look at, but it can be important not to get distracted by valueless tasks. As long as there is a wiki page explaining what to check out (i.e. an entry point for SVN), the layout is fairly moot. You could spend hours (or, encountering errors, days and even weeks) fiddling around making SVN look perfect but what do you gain from it?

When time is key (and this is moreso in open source than commercial development) it's about carefullly choosing what to work on, what adds most value in terms of 1) moving the project forward and 2) building the community (noting that #2 often leads to #1).
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: SVN and current codebase. Cleanup?

Post by chuck_starchaser »

charlieg wrote:I understand that SVN is not pretty to look at, but it can be important not to get distracted by valueless tasks. As long as there is a wiki page explaining what to check out (i.e. an entry point for SVN), the layout is fairly moot. You could spend hours (or, encountering errors, days and even weeks) fiddling around making SVN look perfect but what do you gain from it?

When time is key (and this is moreso in open source than commercial development) it's about carefullly choosing what to work on, what adds most value in terms of 1) moving the project forward and 2) building the community (noting that #2 often leads to #1).
Charlieg, it's important not to flip-flop on goals along the way. Code clean-up is alrady a task few people are willing to do, because it's un-glorious, un-recognized, thankless...
We are the luckiest among the lucky to have someone like Safemode who is willing to work on it. So, would you please not discourage him.

Each project is different. For some of them, clean-up can be obsessive, if they are very clean already (e,g. Celestia); but in the case of VS, absolutely NOTHING could be more important or more urgent than renamings, refactorings, and yes, all those things that don't change a lot of binary bits . And we've all agreed to this long ago, including you, IIRC. Nothing stands in the way of building a community worse than a mountain of spaghetti code nobody understands.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: SVN and current codebase. Cleanup?

Post by safemode »

dont worry, I'm not discouraged. I understand the concern, but cleanup is not holding back VS's release. In essence, the updater is and has always held back VS releases, rather, the lack of one. Because of it's absence, we wait until a huge amount of changes are made before a release to justify making another huge pkg.

I have to continually keep cleanup separate from refactoring. Refactoring is a big deal and needs to be done at the beginning of what will be a new release, not right before one. Cleanups can happen at any time, as a cleanup should by definition not change anything functionally, or at the very most be a bugfix. It's really easy to want to get into refactoring code. And VS needs a hell of a lot of refactoring (and you have no idea how badly i want to run a code formatter through every C++ file). But what's important right now is squashing compiler warnings, getting any obvious bugs fixed that can be fixed and with any luck getting build and documentation files up to date ( at least when it comes to cleanups and such).

I figured on moving to this task rather than continue the physics stuff so we can get closer to something releasable, plus it lends itself more to sporadic free time. I'll get back to the physics stuff after release, that damn ray collider will get in there. Plus, i think there's a good chance i can replace the other last vestige of home-grown collision detection via the sphere collider. We use a homegrown version to determine when we need to call the more complex mesh collider to see if an actual collision occurred. If i can do that, i can probably simplify the collider subsystem to a single layer instead of the multi-level setup we have now.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: SVN and current codebase. Cleanup?

Post by chuck_starchaser »

Yeah, I shouldn't have bunched cleanup and refactoring together; I guess I meant trivial refactorings, such as creating structs (types) for fuel, force, acceleration, faction, instead of using floats and ints; just for a random example.

EDIT:
Maybe we should work together on it, like say one file per day, I do my things to it, mail it to you, you do your things and commit. Probably it'd get done.
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: SVN and current codebase. Cleanup?

Post by charlieg »

I wouldn't mind chipping in there, it might be a way for me to learn a bit more C++... (I know the ultra basics but not enough to be making any changes without extreme supervision and guidance)
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: SVN and current codebase. Cleanup?

Post by chuck_starchaser »

Swell! :D
It will be your best learning experience, too, with BAD vs GOOD coding examples throughout.
Let's wait and see what Safemode says.
My suggestion of 1 file per day was rather poetic; some files are huge. Also, we'd be well
advised to take one package of closely related classes at a time and discuss common
issues and plan strategy. Some changes will have wide repercussions on other code, such
as making 'faction' a type, rather than have separate faction string and integer id.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: SVN and current codebase. Cleanup?

Post by safemode »

I really really dont mind the idea of totally reworking the code over, in small incremental steps. That's great. I just think it's something that should be put for after we get the next release out and after we have an incremental update system in place to allow such refactoring to not delay any future updates. Because once you start refactoring, you aren't going to be happy with just one little change, a little change will beget bigger necessary changes and bigger until you're rewriting the entire subsystem.

No matter how much you convince yourself it wont get out of hand, it will with VS, because it needs it. I'm all for it, but it's definitely a post-release project.

I would say, we would identify a subsystem to work on after an incremental release is made, refactor it, and be done before the next incremental release and start over once it's made. I dont think we would be able to minimize it to just one class. Usually correctly writing a class requires then to rewrite calling classes to properly use the newer class and possibly rewriting any dependent classes due to requiring correct api usage (so we dont have to rewrite what we just rewrote when we get to those dependents).
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: SVN and current codebase. Cleanup?

Post by chuck_starchaser »

safemode wrote:I really really dont mind the idea of totally reworking the code over, in small incremental steps. That's great. I just think it's something that should be put for after we get the next release out and after we have an incremental update system in place to allow such refactoring to not delay any future updates. Because once you start refactoring, you aren't going to be happy with just one little change, a little change will beget bigger necessary changes and bigger until you're rewriting the entire subsystem.

No matter how much you convince yourself it wont get out of hand, it will with VS, because it needs it. I'm all for it, but it's definitely a post-release project.
Yeah, I know. Well, no particular rush here; been wanting a cleanup for 7 years; a few more weeks aren't going to break me down.
I would say, we would identify a subsystem to work on after an incremental release is made, refactor it, and be done before the next incremental release and start over once it's made. I dont think we would be able to minimize it to just one class. Usually correctly writing a class requires then to rewrite calling classes to properly use the newer class and possibly rewriting any dependent classes due to requiring correct api usage (so we dont have to rewrite what we just rewrote when we get to those dependents).
Exactly; and probably the worst way to approach the problem is with shyness. I think I'd rather open battle by driving a spear through the heart of the medusa: the unit system.
There's an elegant solution to the collision problem --of consequences being different depending on what's collided with what-- in a book by Scott Meyers I used to have... Ridiculously Effective C++, or something about STL in the title; can't remember now.
The priorities system for frequency of physics updates needs work.
As much as possible the unit system should reuse code. Right now, planets are handled differently from other units. Klauss coded a fabulous shader for planets, but needed to add a texture and couldn't find where it's done. Planets should use one or more bfxm's, NOT procedural spheres. The same trick used for faction-specific textures for units could be used for planet types. So, in the round_planet.bfxm's folder there'd be diffuse.texture, desert_diffuse.texture, vipers_blanket_diffuse.texture, and the same for specular, normalmap, bent_normal, etceteras, as per the technique. Yeah, probably three bfxm's for round planets --one for each technique--: Non-atmo, atmo, and multilayer_cloud (for gas giants). So, planets would work like any other unit, and could allow you to use icosopheres if you want, apply textures as cubemaps, etceteras, instead of forcing the use of geosphere and cylindrical unwrap.
Concepts, such as collidable, tractorable, pilotable, chewable, spittable, blowuppable... should use the Barton-Nackman trick. So, we'd create a collection of abstract types from this sparse array of conceps by muliple inheritance in the abstract; then, concrete unit types would inherit AbstractUnit and one MetaConcept.
Behaviors, such as AI, are a different story, and they should not use virtual functions; they should use the Visitor Pattern, instead, which avoids vtable complexity by turning the problem 90 degrees, into a function overload table, which is a compile-time solution.
Besides, visitors can have state, so all of the ai could be implemented as tasks having state and visiting the ai units.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: SVN and current codebase. Cleanup?

Post by safemode »

I wonder if perhaps planets didn't use meshes because they were so ginormous. Like, really really massive objects that needed to retain their roundness without requiring millions of polys.

If we can do that with meshes in some way, so we can treat them the same as any other unit, then that would be great. I just think that the original writers would have done so if they could, as that would be the easier solution, not cooking up a separate method.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: SVN and current codebase. Cleanup?

Post by chuck_starchaser »

safemode wrote:I wonder if perhaps planets didn't use meshes because they were so ginormous. Like, really really massive objects that needed to retain their roundness without requiring millions of polys.
Perhaps there was the idea of using some kind of on-demand tesselation algorithm; you may be right; but that's not what was implemented. The number of wedges and rings is fixed; you can set it, I can't remember if it's in vegafig or some other xml file somewhere. And real-time tesselation in the gpu is a DX11 feature coming up and we may want to use it for ships too, btw. So, regardless, I don't see the need to have completely separate systems.
If we can do that with meshes in some way, so we can treat them the same as any other unit, then that would be great. I just think that the original writers would have done so if they could, as that would be the easier solution, not cooking up a separate method.
I've given up trying to second-guess the original writers :D Hellcat's favorite phrase is "that's like that for historical reasons"... But, whatever... Suppose we decided tomorrow we want flyable planets with continuously expanding, procedural LOD's, and this requires a special file format. So what? We can add its format to bfxm, and still use a unified data management organization.
Post Reply