[Inquisitor]

I want to get folks together to talk about the next build. It's been too long, and there is some good owrk in the open branch (not to mention the DX branch).

I also had a suggestion that we needed another branch, for release/stable builds, and I would like to act on that sooner rather than later, it would solve some of the concerns that some of our developers have had.

I am going to the Indie Con this weekend, so, I can have a meeting the following weekend if that works for everyone. that would be Nov 9th I think, at 1300hrs EST.

What say ye?

[Sesquipedalian]

Stable builds=good.

[Fury]

OK, I didn't quite understand what Inquisitor meant.
So ignore my original message.

[RandomTiger]

Originally posted by Inquisitor

I also had a suggestion that we needed another branch, for release/stable builds

If you mean a CVS branch then I think thats a really bad idea.
Is the current branch unstable?

[Inquisitor]

We can discuss.

I mean a branch that we do code reviews of before committing to, and a branch that we are continually working on (that, at any point in time, may not actually compile).

We need to balance the collaboration/backup needs against the "I only want stable stuff in CVS."

So, you may think it's a bad idea, and you may be right, but, it rang true as a possible approach to solving the problem that you yourself indicated with CVS That and your boy Slade was the one who suggested it. Give the project a little more structure.

It's a discussion point I want to raise with the group

[RandomTiger]

Originally posted by Inquisitor
and a branch that we are continually working on (that, at any point in time, may not actually compile).

Thats the worst case situation when it cant compile becuase if someone whats to update or commit they have to fix someone elses code.

If that starts happening people will either comment out each others changes that dont compile because they cant be arsed (and fair enough) to sort out other peoples code or will just update and commit less often.

Its only happened to me once but it was the most annoying thing we should avoid at all cost. A total waste of programming time.

If you set slow standards for a 'frequent commit' branch then you will end up with low standard work.

A better solution to the situation would be for coders to take up the responsiblity of intergrating their new code correctly, use the testing resources they need and have all the information they may need in an online knowledge base about this project.

[Inquisitor]

Which is not something that will always happen. I don;t know how to explain that to you.

We don't get frequent enough committs, therefore we don;t get builds of substance, I need to rectify that.

This is HOW everyone in the world uses CVS, regardless of whther we have a dev branch, we need to get more code in more often. A "stable" branch gives us some comfort in the fact that anything that goes in there has been peer reviewed (at least that's my thought on the review process, also open for discussion), and guarantees we get code into our hands. CVS is "Concurrent Version System" that means it EXPECTS more than one person to be working on the code. THat's WHY you update before you committ, to catch changes. It's a collaboration tool.

Bad committs get rolled back, that's how it works. The seperate branch was a SUGGESTION on how to mitigate the whole "in progress code" problem that everyone seems to be afraid of and convince people to get their code in more often.  There's unit testing, then there's fear of the unknown. The ONLY way to get some of this tested is if people have it.

It's supposed to be my job to get code in. This is how I want to manage it. We use CVS and rollbacks to make sure your issue doesn;t happen. We're not lowering any standards. If anything, we're raising them. Code gets reviewed by people more often, suggestions for making it better can be made in context.

Collaboration.

Useful subsection from CVS documentaion, if you are REALLY afraid someone will muck up something you are currently working on, lock the files (warning, I WILL unlock files if they remain locked for an inordinate amount of time, use this feature sparingly):

3.11.2 Understanding Locking and the Reserved Checkout Model

As stated in Section 3.11, cvs does provide a mechanism to support the reserved checkout model. The lock command is the basis of this model. Locking a file in cvs prevents another developer from either locking or committing a new version of the file. This is safe in that it does prevent the other developer from checking in a new version of the file but it does allow another developer to edit the file. This could lead to frustration, for example, if a developer forgets to get a file lock but just edits the file. When the developer attempts to commit the file, the operation will fail as shown in the following example:

cvs -q commit -m "This is the change from user 2\n\n" gascal.c (in directory E:\WorkAreaTwo\EtchPM\src)

cvs [server aborted]: Revision 1.7 is already locked by apples

*****CVS exited normally with code 1*****

If all developers cooperate and ensure that files are locked prior to editing, this situation need not arise. Alternatively, the unreserved checkout model could be used.

As with other commands, WinCvs provides several ways to invoke the lock command:

Select the file(s) using the left mouse button and use Selections menu:
Selections->Monitors selection->Lock selection

Select a file using the right mouse button and choose Monitors selection->Lock selection
Select the file(s) using the left mouse button and use the tool bar icon:
 

Use the unlock command to unlock the file in one of several ways:

 

Select the file(s) using the left mouse button and use Selections menu:
Selections->Monitors selection->Unlock selection

Select a file using the right mouse button and choose Monitors selection->Unlock selection
Select the file(s) using the left mouse button and use the tool bar icon:


If a lock request succeeds, the following messages will be displayed on the status window:

cvs -q admin -l gap_lp.c (in directory E:\WorkAreaTwo\EtchPM\src)

RCS file: /Store/200mm/EtchPM/src/gap_lp.c,v

1.2 locked

done

*****CVS exited normally with code 0*****

If a lock request fails, information including the owner of the lock will be displayed:

cvs -q admin -l gascal.c (in directory E:\WorkAreaTwo\EtchPM\src)

RCS file: /Store/200mm/EtchPM/src/gascal.c,v

cvs [server aborted]: Revision 1.7 is already locked by apples

*****CVS exited normally with code 1*****

[Sesquipedalian]

Well, I'm in favour of the idea of a stable build branch.  The current branch will continue to function exactly as it does now.  the stable build branch is just for commiting code to once the coder is finished with it -- you work in fs2_open and we all do our stuff in there, and when all of a certain bit is finished, it is put into fs2_stable to be available for release to the public.

[Bobboau]

and it looks like somehow my mysterious locking has gone away
I shal commit tonight if it doesn't happen
and I have the new glow point code working (with the new version of PCS I made)

[Righteous1]

Another option would be to maintain fs2_open as the 'stable' baseline.  If someone is working on a major update (ex. directx8), request a working branch to be set up for that update.  Once the update is complete, then it can be merged back to the baseline.

Or perhaps set up a separate working branch for each programmer  so they can work without risk of impacting anyone else then merge with the baseline when they're done.

[RandomTiger]

Originally posted by Bobboau
and it looks like somehow my mysterious locking has gone away

Sorry to OT but, its bound to come back at the worse moment.

[Bobboau]

well it seems my reverting to an old osapi didn't take effect untill last night (got a bunch of odd include errors from it) and it hasn't locked sence, though I could just be getting lucky again, it has been very stable though,

[Bobboau]

here is my current build, and some files you'd need to see changes, note on the orion, it now has lights that blink in sequence along the launch strip thing

I'm going to update and commit in a second

[updated]

got a mismatched if-endif thing in Cmdline.h, I'm gona put an endif at the end of it and see if it works...

seems something with the mod handeling code isn't playing well

mes thunks DTP forgot file type 64 in cfile.h

Code: [Select]


#define CF_TYPE_MOD_PLAYERS 62
#define CF_TYPE_MOD_SINGLE_PLAYERS 63
#define CF_TYPE_MOD_MULTI_PLAYERS 65
#define CF_TYPE_MOD_MULTI_CACHE 66
#define CF_TYPE_MOD_CONFIG 66
#define CF_TYPE_MOD_SQUAD_IMAGES_MAIN 67


ok now it's getting an unhandeled exception while reading a wav right in the middle of a vp file
this line
strcpy( file->name_ext, find.filename );
in
cf_search_root_pack
is crashing when reading, of all things, SM202_A2_02.wav from within stu_fs2.vp

I am going to sleep now

[RandomTiger]

Check your mail Bob

[Bobboau]

RT just pointed out that I had forgoten to include some files in that build, so redownload if you would

[EdrickV]

Rather then calling it a "stable" branch, calling it the "release" branch might sound better. Same thing, different name, and still a good idea IMHO. Though, until there's a working GCC makefile again, I'm not sure how useful it will be to most people. (The people who have VC++ are probably the ones working on the code. Those without VC++ can't do anything with the code unless they're running Linux.) It would be a good safety net, marking release versions that people could download, compile, and actually use.

[Bobboau]

does the current CVS compile for anyone else?
I just checked out a copy and it won't compile

[RandomTiger]

[Inquisitor]

Bob, tell us what it's failing at.

Also, if it's the 2 new updates to the sexp's, you can retreive versions of those before yesterday in the CVS checkout options tab, right click on the sexp files, select update, and in the branch/tag tab, enter the date that you want.

[DTP]

Originally posted by Bobboau
here is my current build, and some files you'd need to see changes, note on the orion, it now has lights that blink in sequence along the launch strip thing

I'm going to update and commit in a second

[updated]

got a mismatched if-endif thing in Cmdline.h, I'm gona put an endif at the end of it and see if it works...

seems something with the mod handeling code isn't playing well

mes thunks DTP forgot file type 64 in cfile.h

Code: [Select]


#define CF_TYPE_MOD_PLAYERS 62
#define CF_TYPE_MOD_SINGLE_PLAYERS 63
#define CF_TYPE_MOD_MULTI_PLAYERS 65
#define CF_TYPE_MOD_MULTI_CACHE 66
#define CF_TYPE_MOD_CONFIG 66
#define CF_TYPE_MOD_SQUAD_IMAGES_MAIN 67


ok now it's getting an unhandeled exception while reading a wav right in the middle of a vp file
this line
strcpy( file->name_ext, find.filename );
in
cf_search_root_pack
is crashing when reading, of all things, SM202_A2_02.wav from within stu_fs2.vp

I am going to sleep now [/B]

is it not amazing how an error i thought i had corrected long ago is still there.

dam this is, sloppy of me, next time i'll not commit before im sure it all works.