On Jun 22, 2008, at 2:47 PM, Benoit St-Pierre wrote: > Alexander, > > I like the ideas you are putting forward ! > > **Unique Ids**. ~~ Those little gremlins are what makes a database > a real database. We should normalize to a point we get those for > all the essential parts of our information system. All the work my > friend is doing is of absolutely no use because he prefers to trim > down all his information to a bare minimum : he's building his > repertoire, history is of no concern to him.
I was hoping to keep all information intact (i.e., the seven-tag roster plus any other information present). > > > **Database versions**. ~~ The trichotomy cutting edge / stable / > old (or whatever) is interesting. It's common practice and it's > simple. Good idea. > > > **Concurrency problem**. ~~ That's where the real threat lies. > Suppose we could do like Scid source. That would mean very huge > dowloads and uploads ! Very inconvenient for minor revisions. > Just imagine 10 persons that commit each week. > > > **Possible solution**. ~~ The only reasonable idea, as far as my > one hour commuting reflexion led me, is to work it piecemeal. If > someone is working in some subset of games, his work could be > announced on the game or tournament list form I was alluding to > sooner today. (I don't know if Trac could do that, anyway, let's > speak theorically.) The person that is adding or correcting some > games send those to a repository. Each nighly (let's stay humble > and say monthly) build then merge all the games into one of the dev- > db. Good solution. Do you suggest keeping the subsets of games in pgn format? Let me tell you where I am coming from. I am not a programmer and have little experience with multiple users working on a common project, so "CVS" and similar terms are new to me. I do use scid and this has helped my chess learning immensely. I am looking for something I can do to contribute something useful. This appears to be something I can do. Just let me know how I can best contribute. > > > **Automatic maintenance**. ~~ If we go so far, that would be > stupendous. But here lies the second big threat : once we have a > monthly build, who will maintain ? Let suppose someone takes > charge of this, and let's call him C*, for no reason > whatsoever ;-) Well, C* will get tired of all this manual manips. > And when tired, there are fair chances C* will become error-prone. > Besides, how is C* supposed to tell what are the effects of his > manips ? So we should try to automatize this to a point where a > simple Diff would do the trick, at least to generate the Revision > History Sheet. > > I am getting a bit afraid by the size of the effort it seems to > take. So I will rest now. > > Until later, > > B > > > > ---------------------------------------------------------------------- > --- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/ > index.php_______________________________________________ > Scid-users mailing list > Scid-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/scid-users Thanks, Cory Cory Helfrich [EMAIL PROTECTED] ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
