Announcement

**vovan** · June 8, 2003, 19:30

Well, there is actually another reason I had in mind for getting CVS that I forgot to mention:

You see, I have already started integrating my Diplomacy system with the rest of the game. So, I had to edit a bunch of classes that have already been written, like Civilization, Coordinator, ClashWindow, and some others. Now, when I actually get the latest version of the code, I imagine a lot of these classes have been altered as well. I am afraid it will be a big pain to detect the changes I made, and the changes made to the same classes by other people, and merge them together. Now, CVS simplifies the task a lot. So that's another thing to consider: any time two people make changes to the same class, Mark doesn't have to go through the code looking for differences.

**LDiCesare** · June 8, 2003, 19:58

I agree a CVS repository would help, but want to point out that -very often, when merging code with someone, you have to ask that other person what they wanted to do in order to merge properly (it's my working experience), -there exist some diff tools (vdiff32, CSDiff, -d option in gvim,...) which can help find differences in files rapidly and merge them more or less easily.
But yes, there are surely some conflicts between files (Coordinator, and maybe ClashWindow).

**vovan** · June 8, 2003, 20:17

Laurent, I certainly understand that when merging files you can't rely entirely on the programs to do it, and have to manually check what changes have been made in order to not mess up something. But the problem I think I will face when the new version of the code is available is this:

I hate to admit it, but I don't remember all of the files that I changed. So, suppose, I get the new version of the code and I put it into the folder with my working code. The files that have been updated will pop up a warning about replacing them with a newer version. Now, if I had done all the code recently, I would just be able to say: oh, since this file is newer, it must have only my changes, and cancel the overwrite. But since some of the changes are quite old, I can't really tell if the new file is different from the old file because I edited the one on my machine, or someone edited the new file, or both. That is the main problem that is going to happen. Before, I used to keep track of files I have updated by utilizig the search feature: you see, I use emacs to code Java. And when you edit a file, emacs saves the original version in a temporary file. So, I could simply do a search for *.java~ files in my working directory, and see immediately which files I changed. But now, since I had to reformat the hard drive a couple of times in the period I was inactive, the temporary files are gone, and there really is almost no way of telling which files I edited. (Well, I think I put all of them into my little Change History list I keep, but I may have missed some, especially if the changes were failry small.)

Also, I would like to say that I took the freedom to submit a new project request for Clash on Sourceforge. After all, I figured, if we decide against it, we can always just abandon it.

**LDiCesare** · June 8, 2003, 20:50

I hate to admit it, but I don't remember all of the files that I changed.

You're not the only one

.

When I get a lot of modifications, I usually go through the process of checking dates of files. Zip, when used correctly, keeps the dates. With a quick filter on dates of files, you can usually end up with a list of maybe-modified files. A quick diff on these does the job.
I agree that CVS would be easier, mind you. I'm just saying it will not prevent us from merging things the hard way. For instance at work, I've done a simple change. I added a pure virtual class on top of a class in C++ code, and changed the reference to that class in two data members. I ended up modifying about 200 files just for that.

(you can start imagining the mess of a code I have to maintain) Of course, other people modified stuff therein too, and I ended up merging some of these files daily. The tool we use (not CVS, probably worse than CVS as far as I remember) didn't help much.

**Mark_Everson** · June 8, 2003, 21:19

Hi, I've only got time for some quick comments. If you make changes in code that isn't 'yours' you are supposed to be putting comments something like //*V (for Vovan) before blocks of code you changed. That way we can easily track down code collisions.

Originally posted by vovansim
Also, I would like to say that I took the freedom to submit a new project request for Clash on Sourceforge. After all, I figured, if we decide against it, we can always just abandon it.

Sourceforge is for only Open Source projects. Clash is not. . . We would need to have someone create a CVS setup.

I will go with whatever the more experienced programmers want to do. I certainly do want to get out of the "mergers by hand" business.

-Mark

**Gary Thomas** · June 8, 2003, 22:06

I have been in favour of a CVS repository from the beginning. As Mark says, Clash is not open source and hence is not suitable for SourceForge. What we need is someone with access to a server, to host the CVS repository, and someone reliable to manage it.

And there, as the bard noted, is the rub.

I have experience at running a CVS repository, and hated it. Also, I do not currently have much time available, though I admit, a CVS repository does not need much time.

If we can locate a server, I might consider administering the CVS.

We have had an enormous amount of trouble in the past with merging code, and that was with only three coders. It is a serious problem.

There are two other factors.

One is that the core classes should get to the stage where modification is rare. There had been something of a habit for people to hack around with core classes like Civilization or Administrator because they wanted a quick and nasty solution to an immediate problem. The difficulty with such solutions is that the advantage of "quick" is soon gone, the disadvantage of "nasty" is there until someone takes the time to do it properly. If I was running it I would lock the core classes and need a change request before letting people at them. Ha! the (slightly) suppressed dictator personality is now emerging.

The other is that I always wanted each model to have a single interface which is referred to in only a single core class. Then the model, provided it implements the interface, could be modified without affecting the rest of the program. The technology model was pretty much implemented in that way, though it has been compromised somewhat since then.

If these priciples were adhered to, the need for CVS would be much less.

Cheers

**vovan** · June 9, 2003, 00:11

In response to everything above:

1. Sorry, I somehow missed the part that Clash is not open-source. I suppose, if it was open-source, then you would have started an SF project a long time ago.

2. Mark, yes, I put detailed comments whenever I change classes outside the diplomatic model. I denote the changes with both inline comments and at the beginning of the file. (I also increment the version counter at the top of the file, which nobody has been doing before, it seems.

) So, there is no problem identifying what I have changed. The problem is that there are so many files, that it is going to take a long time going through each of them and seeing if I had changed anything there (though since I pt the summary of the changes with the date of the change in the header, I won't have to filter through the code in search of the //*V

).

3. Gary, I can give enough justification for changing the core classes.

I, personally, hate it when people mess with my code. Hence, I don't like messing with other people's code much.

Well, alright. No CVS then, it seems, for now at least.

Announcement

Time to consider Sourceforge again?

Time to consider Sourceforge again?

Comment

Comment

Comment

Comment

Comment

Comment

Comment