PROJECT: New coding methodology

[J Bytheway]

Assuming all goes well we should have a subversion server (and possibly, in the long term, other things such as bugzilla ), thanks to kaan (see this thread).

Given this, we have to make some decisions about project strategy, including at least the following:

What should we do about the ACTIVISION_ORIGINAL convention?

Personally, I say we should scrap it because it clutters the source code unnecessarily and all the information about changes is there in the version control if it's needed.

Should we keep posting updates to the Altered source files thread?

I think probably not. It's simply not worth the trouble to the coders, compared to the convinience of version control. However, I think it's probably still worthwhile posting periodic all packs (which, again, should be made easier by version control).

Anything else?

Discuss.

[Solver]

I have been in favor of scrapping the ACTIVISION_ORIGINAL for some time now... with version control, we definitely should, even if we screw something up, we can revert it easily.

As for posting changes in a thread... it might still be useful. For instance, we need to look at how easy it is to keep the local copy on everyone's HDD in sync with the one at CVS. If such issues are solved easily, then the altered files thread might be redundant.

[J Bytheway]

Originally posted by Solver
As for posting changes in a thread... it might still be useful. For instance, we need to look at how easy it is to keep the local copy on everyone's HDD in sync with the one at CVS. If such issues are solved easily, then the altered files thread might be redundant.

Assuming people are willing to subscribe and everything goes smoothly then it should consist of simply opening a console in the appropriate directory and type "svn update". Or, if you've installed something like TortoiseSVN, you can just right click on the directory in explorer and tell it to update there.

In theory it's all smooth sailing...

Of course, it's nice to be notified by email about new changes, but the subversion server can be set up to send out emails too.

[ctplinuxfan]

Well, that's really great news!

For the main questions, i'd vote:
[X] Remove APOLYTON_ORIGINAL tag
despite the higher complexity stated earlier:
- You may thing you'd get an original build, but you would not
- Instead, a tag for apolyton original within subversion repository does the same
- we all have the orignial sources, haven't we?

[X] No further posts to kind of altered source files threads
- Syncing threads with repository is error prone
- svn update is faster than download and unzip patch1, look for conflicts, apply, download and unzip patch2, look for conflicts, apply, download and unzip patch3, look for conflicts, ...

[X] See, if sources are demanded packaged though we have subversion.
- If they are, provide a complete source package from time to time (no all patch)
Alternative a) It's a simple svn export and zipping the directory
Alternative b) it's a zipped checkout from the subversion server (i.e. double size), but users can update without using too much bandwith
- These tasks are scriptable

PS: Sorry, if i'm still a bit inresponsive, i've a lot of work to do and am moving...

[Fromafar]

APOLYTON_ORIGINAL tag: While I prefer removing it, I realise this means a lot of work, without any obvious benefits. Maybe we should just be lazy and opt for just not actively supporting it anymore. Did anyone change their vote since the last poll? IIRC it was 3 in favour of removal, 5 against.

Posting updates: I have mixed feelings about this. I agree with the listed reasons in favour of stopping, but I fear that this will be bad for the project. It now serves as a kind of progress report, and may motivate people to play/test, because they can follow what is happening. It may be undesirable to have this information only available for a limited group/through a version control system.

[J Bytheway]

Originally posted by Fromafar
APOLYTON_ORIGINAL tag: While I prefer removing it, I realise this means a lot of work, without any obvious benefits. Maybe we should just be lazy and opt for just not actively supporting it anymore. Did anyone change their vote since the last poll? IIRC it was 3 in favour of removal, 5 against.

Surely they can be automatically removed. I would have thought that the C preprocessor should be able to do this, but if not I'm fairly sure I could throw together something to do it pretty quickly.

Posting updates: I have mixed feelings about this. I agree with the listed reasons in favour of stopping, but I fear that this will be bad for the project. It now serves as a kind of progress report, and may motivate people to play/test, because they can follow what is happening. It may be undesirable to have this information only available for a limited group/through a version control system.

Perhaps it would still be good to post about updates, but rather than an attachment of the update, simply note the revision number.

[J Bytheway]

Well, now we have the svn server all properly set up, I'm planning to purge all the ACTIVISION_ORIGINAL directives. Does anyone object?

[Ekmek]

I don't object to the ActOrig stuff since I had a rough time trying to follow it anyways.

As for Altered Files, I prefer saving, mainly because Amateurs like myself probably still need our stuff checked before it gets put on the server. Plus, I havent been able to access the server and not sure I can do the updating.

[kaan]

E, you will need to apply for a username/password to be able to use the svn server.
Either mail me or send me a private message with the username and password you want.
Remember to include a statement that says that you have read the Activision source code license and agreed to it.

-klaus

[Martin Gühmann]

Originally posted by J Bytheway
Well, now we have the svn server all properly set up, I'm planning to purge all the ACTIVISION_ORIGINAL directives. Does anyone object?

Two objections that have to be cleared first. I added for documentation comments like: // Added by Martin Gühmann

With removing ACTIVISION_ORIGINAL derectives, that looks odd. And the second is that I used something like followning to comment out some of Calvitix changes:

#if 1 || defined(ACTIVISION_ORIGINAL)
// Original code
#else
// Calvitix code
#endif

What happens with this if you purge the ACTIVISION_ORIGINAL derectives?

-Martin

[J Bytheway]

Originally posted by Martin Gühmann
Two objections that have to be cleared first. I added for documentation comments like: // Added by Martin Gühmann

With removing ACTIVISION_ORIGINAL derectives, that looks odd.

Why? I guess it no longer has the delimiters it used to have, but the comment is still accurate and in the right place...

And the second is that I used something like followning to comment out some of Calvitix changes:

#if 1 || defined(ACTIVISION_ORIGINAL)
// Original code
#else
// Calvitix code
#endif

What happens with this if you purge the ACTIVISION_ORIGINAL derectives?

Well, the way I was planning to do it, that would become:

#if 1
// Original code
#else
// Calvitix code
#endif

(In other words, change things by assuming ACTIVISIoN_ORIGINAL is false, but don't make any other assumptions (Like that 1 is true)).

That should be moderately easy to automate.

[Martin Gühmann]

Originally posted by J Bytheway
Why? I guess it no longer has the delimiters it used to have, but the comment is still accurate and in the right place...

That's right that is at the right place marking the start of the alteration but not the end.

-Martin

[J Bytheway]

Originally posted by Martin Gühmann
That's right that is at the right place marking the start of the alteration but not the end.

But that's what version control is for. For example, if I do svn blame ctp2_code/gs/world/UnseenCell.cpp, a part of the output looks like this:

     1 activision               archive >> l;
   266 Martin G├╝hmann
   266 Martin G├╝hmann #if defined(ACTIVISION_ORIGINAL)
   266 Martin G├╝hmann // Removed by Martin G³hmann
     1 activision               for(i = 0; i < l; i++) {
     1 activision                       m_installations->AddTail(new UnseenInstallationInfo(archive));
     1 activision               }
   266 Martin G├╝hmann #else
   266 Martin G├╝hmann // Added by Martin G³hmann
   266 Martin G├╝hmann          UnseenInstallationInfo* tmpUII;
   266 Martin G├╝hmann          bool vCityOwnerNotSet = true;
   266 Martin G├╝hmann          for(i = 0; i < l; i++) {
   266 Martin G├╝hmann                  tmpUII = new UnseenInstallationInfo(archive);
     1 activision
   266 Martin G├╝hmann                  // Only store the additional UnseenInstallationInfo in the
   266 Martin G├╝hmann                  // save file but not in the UnseenCell object itsself.
   266 Martin G├╝hmann                  if(tmpUII->m_type >= 0){
   266 Martin G├╝hmann                          m_installations->AddTail(tmpUII);
   266 Martin G├╝hmann                  }
   266 Martin G├╝hmann                  else{
   266 Martin G├╝hmann                          m_visibleCityOwner = tmpUII->m_visibility;
   266 Martin G├╝hmann                          vCityOwnerNotSet = false;
   266 Martin G├╝hmann                          delete tmpUII;
   266 Martin G├╝hmann                  }
   266 Martin G├╝hmann          }
   266 Martin G├╝hmann          // Backwards compartibility: If this UnseenCell didn't have an m_visibleCityOwner
   266 Martin G├╝hmann          if(vCityOwnerNotSet) m_visibleCityOwner = g_theWorld->GetCell(m_point)->GetCityOwner().m_id;
   266 Martin G├╝hmann #endif
   266 Martin G├╝hmann
     1 activision
     1 activision
     1 activision               m_improvements = new PointerList;
     1 activision               archive >> l;
     1 activision               for(i = 0; i < l; i++) {

And after removing the ACTIVISION_ORIGINAL stuff, it should look like:

     1 activision               archive >> l;
   266 Martin G├╝hmann
   266 Martin G├╝hmann // Added by Martin G³hmann
   266 Martin G├╝hmann          UnseenInstallationInfo* tmpUII;
   266 Martin G├╝hmann          bool vCityOwnerNotSet = true;
   266 Martin G├╝hmann          for(i = 0; i < l; i++) {
   266 Martin G├╝hmann                  tmpUII = new UnseenInstallationInfo(archive);
     1 activision
   266 Martin G├╝hmann                  // Only store the additional UnseenInstallationInfo in the
   266 Martin G├╝hmann                  // save file but not in the UnseenCell object itsself.
   266 Martin G├╝hmann                  if(tmpUII->m_type >= 0){
   266 Martin G├╝hmann                          m_installations->AddTail(tmpUII);
   266 Martin G├╝hmann                  }
   266 Martin G├╝hmann                  else{
   266 Martin G├╝hmann                          m_visibleCityOwner = tmpUII->m_visibility;
   266 Martin G├╝hmann                          vCityOwnerNotSet = false;
   266 Martin G├╝hmann                          delete tmpUII;
   266 Martin G├╝hmann                  }
   266 Martin G├╝hmann          }
   266 Martin G├╝hmann          // Backwards compartibility: If this UnseenCell didn't have an m_visibleCityOwner
   266 Martin G├╝hmann          if(vCityOwnerNotSet) m_visibleCityOwner = g_theWorld->GetCell(m_point)->GetCityOwner().m_id;
   266 Martin G├╝hmann
     1 activision
     1 activision
     1 activision               m_improvements = new PointerList;
     1 activision               archive >> l;
     1 activision               for(i = 0; i < l; i++) {

So it's obvious where your modification ends. The information is there if necessary, and even then I don't think it would be particularly useful very often.

[Martin Gühmann]

Originally posted by J Bytheway
So it's obvious where your modification ends. The information is there if necessary, and even then I don't think it would be particularly useful very often.

But then the comment is useless in the end. However this should be now all. But maybe you should wait for E to allow him to make his code right. Of course can remove them per hand or it can be repeated.

And there is another precompiler derective you should strip: NON_STANDART_C_PLUS_PLUS

I only used in tech_wllist.h, Fromafar never used this. So it is obsolete as well.

-Martin

[J Bytheway]

Well, after working on this all day I think "moderately easy to implement" was a little optimistic. I've had all sorts of problems I didn't expect due to such things as comments, different line-ending styles, missing terminating newlines, and, of course, Martin's endlessly frustrating umlauts .

However, I think I'm probably done. I'm staring at the steady progress of processing now. If ever anyone wants code to automatically manipulate preprocessor directives, then just ask - I have a very versatile system now .