SVN and me

[vovan]

Guys,

I just wanted to say that I am still around.

Basically, my only computer's hard drive died last week, and so I spent the majority of the time trying to restore some of the data off it (unsuccessfully) and then trying to catch up on the school work which I didn't have backed up.

Any way, I yesterday received a replacement hard drive for the laptop, and so am now in the process of restoring all the software on it: you know, windows, office, visual studio, emacs, java and such things.

Now, as regards to the SVN server. I checked it just now, and it was down. This happens sometimes when the hosting company does maintenance on the servers, which sometimes requires a restart and the SVN server doesn't always go up automatically. It should now be fully operational, and also I checked and saw that the latest commit was this sunday, so hopefully the server wasn't down so long as to cause any inconvenience. None of the data seems to have been corrupted, and plus, like I said, automatic nightly backups are being made to a different machine, so there shouldn't be any problems with losing anything.

Cheers,

Vovan

[Mark_Everson]

Hey Vovan:

Sorry to hear about the comp. issues. I was away at a SF con with my wife, and havent committed anything in a while, so probably everything is up to date since Laurent only commits on the weekend.

Cya,

Mark

[LDiCesare]

Sorry to hear the hard drives problem. It's really bad when that happens. I indeed commit only on week ends (except when I am on vacation), so I didn't lose anything.

[LDiCesare]

This is mostly a coding standards topic.
Vovan took great pains to reorganize the imports so instead of having
import package.*;
we have
import package.class1;
I must say that, for compilation reasons, this is a good move, and when I started coding, I was a proponent of that approach.
But then Gary told me that using import package.*; saved developper time, and we decided to stick to the import package.* for all the code (with the occasional exception here or there).
I now have a bunch of modifications which needed 1 month of work for me to get it to merely compile. This included adding some new requirements and removing others. Since SVN does automatic merges (ARGGGHHHHH!!!! NEVER automatic merge), I end up with stuff like this:
.\game\interfaces\Square.java:261: cannot resolve symbol
symbol : class ProvinceRiotData
location: interface game.interfaces.Square
public ProvinceRiotData getRiotData();
And I get that for well, just about every file that has been modified. So I will still have to take an hour or so to get everything to compile instead of debugging my stuff.

We had agreed with Gary to have import * because it makes coding easier, but we didn't document that. I guess it's just in a deleted mail or maybe lost somewhere in a thread here.

So please do not change an import * to a specific import, because it makes changing the code harder.
For instance if I had:
Collection list = new LinkedList();
and realise it's more performant to do
Collection list = new ArrayList(12);
With import * I have just that line to change, with specific imports I must do
-remove import java.util.LinkedList after checking it wasn't used anywhere else in the file (which may actually be harder than just grepping if you made some implicit calls to it by chainging methods like getLinkedList().get(i))
-add the line java.util.ArrayList;
which is about three times more work.
More work to do the same job is bad, so I'd rather not do it.
I'll be reverting files as I need to, but wish I knew how to revert to a version prior to a merge.

I should probably write a coding standards document so this kind of troubles doesn't happen anymore.

[vovan]

Laurent, sorry about that. I should have posted here before doing that. If you haven't yet spent the time trying to fix this, I can easily roll back the one revision that changed the imports. Would you like me to do that?

[LDiCesare]

I corrected my files. There's no use to lose more time on the subject.. You can rollback if it's easy for you but it's not thatimportant since I managed to have the thing compile. Now I must get it to run without crashing...
I committed a codingstandards document in the docs directory, which mostly sums up the points made by Gary in his design document, but is shorter and more focused so if any other standards probem arises, we can register the decision taken therein and not lose it.

[LDiCesare]

I cannot access the repository any more. I get a 404 when trying to connect to the site and an error:
PROPFIND of '/': 200 OK (http://www.vovan.net)

[LDiCesare]

Although I manage to reach the repository, I still can't work on the scenarios subfolders: I can't commit changes to dawn1.xml or reinforcementTest.

[LDiCesare]

I can no longer commit anything to the repository. Not even the code (which used to work till last week).
I haven't heard from Vovan for a while too, so I'm beginning to become a little concerned.

[Mark_Everson]

I think that until Vovan can address the problems we need to go back to the zipped code and resources approach that we were using a while ago.

I unfortunately have had virtually no time for Clash, so it's likely to only be a big issue between you and alms for the near future.