C2C SVN Changelog

[Dancing Hoskuld]

Note after the latest SVN change none of my units can move anywhere!

 

[Thunderbrd]

SVN 7379/7380
Units are able to move again & ZoC should be operating properly.

 

[strategyonly]

7381 changed this to 131, with the paging system, it doesN'T make any difference is turn times. So i'd rather see ALL the buildings, for now.

<Define>
<!--
Use the following to determine what building art is displayed on cities. It is a bitmask of flags which may be added together:
1 = Wonders
2 = city defences


128 = other
We (used to) default to Wonders and city defenses

(1+2 = 3)
-->
<DefineName>SHOW_BUILDINGS_LEVEL</DefineName>
<iDefineIntVal>131</iDefineIntVal>
</Define>

 

[Stormwind]

7381 changed this to 131, with the paging system, it doesN'T make any difference is turn times. So i'd rather see ALL the buildings, for now.

<Define>
<!--
Use the following to determine what building art is displayed on cities. It is a bitmask of flags which may be added together:
1 = Wonders
2 = city defences


128 = other
We (used to) default to Wonders and city defenses

(1+2 = 3)
-->
<DefineName>SHOW_BUILDINGS_LEVEL</DefineName>
<iDefineIntVal>131</iDefineIntVal>
</Define>

It wasn't meant to be for turn times, it was one of the first, if not the first, measure taken to reduce memory footprint. While it may be outdated with view ports/paging it still might help in the endgame.

 

[JosEPh_II]

It wasn't meant to be for turn times, it was one of the first, if not the first, measure taken to reduce memory footprint. While it may be outdated with view ports/paging it still might help in the endgame.

Agreed. +1

JosEPh

 

[strategyonly]

7382 fixed Art/Units/City_Guard/Musketman.kfm to Art/Units/Musketman/Musketman.kfm

 

[olduser]

It wasn't meant to be for turn times, it was one of the first, if not the first, measure taken to reduce memory footprint. While it may be outdated with view ports/paging it still might help in the endgame.

I can't test this right now is there a difference in the memory usage between 3 and 131 with the latest svn?

 

[Thunderbrd]

It wasn't meant to be for turn times, it was one of the first, if not the first, measure taken to reduce memory footprint. While it may be outdated with view ports/paging it still might help in the endgame.

Agreed. +1

JosEPh

Was going to point out the same when I saw this this morning but I had to run to work. So... another +1 for that.

 

[strategyonly]

7383 see here: http://forums.civfanatics.com/showpost.php?p=13213174&postcount=15

 

[olduser]

SVN7384

Moved ART_DEF_UNIT_GREAT_HUNTER into the core CIV4ArtDefines_Unit.xml.



SVN7385
Moved the PDB & DLL archive into the Sources directory.

 

[olduser]

I don't like how the svn is used at the moment.

Here are some links

http://blog.jmfeurprier.com/2010/02/08/svn-trunk-branches-and-tags/
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

 

[strategyonly]

I don't like how the svn is used at the moment.

Here are some links

http://blog.jmfeurprier.com/2010/02/08/svn-trunk-branches-and-tags/
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

Should be moved to the discussion thread, thx.

 

[Sparth]

7386
1. grand cleaning in units_sparth.FPK
- more then 230 Mb data out
- ~3700 files deleted

2. also:
- removed Intro.bik
- fixed StoneThrower animations

 

[Dancing Hoskuld]

I don't like how the svn is used at the moment.

Here are some links

http://blog.jmfeurprier.com/2010/02/08/svn-trunk-branches-and-tags/
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

Should be moved to the discussion thread, thx.

It is about using the SVN where else would it be? I'll put the links as "for information in the first post".

 

[Dancing Hoskuld]

7387 updates

- Some Spanish translations by Kroji.
- Remove duplicate Diesel bonus definition from Clock Punk folder.
- Fix Sheep/Goat herd text.

7288 updates

- More Spanish translations. (I am about half way through the files ).

 

[Thunderbrd]

I don't like how the svn is used at the moment.

Here are some links

http://blog.jmfeurprier.com/2010/02/08/svn-trunk-branches-and-tags/
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

I would be very worried that any attempt to adopt these methods (which I must admit the texts on don't get to the point fast enough to hold my attention) would cause more problems among our efforts than they would resolve.

 

[Dancing Hoskuld]

Starting to use a bug tracker may help stop things falling through the cracks. Even if we only use it to register the bug and say when it is fixed ie no assigning of tasks to people and people can volunteer to do them but can also unvolunteer if RL gets in the way.

 

[Sparth]

7389
- fixed Middle Eastern Modern Worker redblob

 

[olduser]

I would be very worried that any attempt to adopt these methods (which I must admit the texts on don't get to the point fast enough to hold my attention) would cause more problems among our efforts than they would resolve.

We are working like this right now.

The Never-Branch system

(Often used by nascent projects that don't yet have runnable code.)

​

•Users commit their day-to-day work on /trunk.

​

•Occasionally /trunk "breaks" (doesn't compile, or fails functional tests) when a user begins to commit a series of complicated changes.

Pros: Very easy policy to follow. New developers have low barrier to entry. Nobody needs to learn how to branch or merge.

Cons: Chaotic development, code could be unstable at any time.

A side note: this sort of development is a bit less risky in Subversion than in CVS. Because Subversion commits are atomic, it's not possible for a checkout or update to receive a "partial" commit while somebody else is in the process of committing.

But i would at least use this one, it's not that different and it helps while working on bigger changes.

The Branch-When-Needed system

(This is the system used by the Subversion project.)
•Users commit their day-to-day work on /trunk.
•Rule #1: /trunk must compile and pass regression tests at all times. Committers who violate this rule are publically humiliated.
•Rule #2: a single commit (changeset) must not be so large so as to discourage peer-review.
•Rule #3: if rules #1 and #2 come into conflict (i.e. it's impossible to make a series of small commits without disrupting the trunk), then the user should create a branch and commit a series of smaller changesets there. This allows peer-review without disrupting the stability of /trunk.

Pros: /trunk is guaranteed to be stable at all times. The hassle of branching/merging is somewhat rare.

Cons: Adds a bit of burden to users' daily work: they must compile and test before every commit.

Instead of just working on the workcopy for weeks you create a Branch there you put your daily changes.
This also makes it possible for yourself to track the changes you made and possible errors in them.
If changes are made in the /trunk you merge them into your branch.
When you are done and your changes are stable you merge the branch back into the /trunk.
Another effect it would enable more then one person to work on a project.

 

[Thunderbrd]

My internet connection makes the simplest commit/upgrade a major time killer as it is. I'll soon be getting in a much better connection with any luck. At that point I'd be more willing to try to work with something along those lines since a major commit won't take potentially the majority of a day's worth of modding time at that point.