2008/6/22 Benoit St-Pierre <[EMAIL PROTECTED]>:
> Having one main database has its problems. Having distributed little
> databases too. For logical reasons that are too long to explain now, I
> think we should have a tool to help the maintenance of both style of
> managers.
>
> But my point was to have means to talk about the current status of the
> elements of the main repository. If someone did research about a game and
> established that, for instance, some game is wanted, he could enter the
> header, waiting the game score to be found out.
This way of proceeding, start doing something and leave unfinished, would
certainly lead to persistent garbage. I don't see the case where you can
enter the moves of a game but you don't know the result.
>
>
> By "dubious", I meant to qualify the correcness of some game information :
> header or score. That could be used if we have fair reasons to believe a
> game was forged, or if we have good reasons to say that a source publishes
> errors. We should ask Alexander about the correct archivistic terminology,
> here. Minimally, we should be able to distinguish the games were
> overchecked and those that were not. The game overchecked by the players
> themselves would get the highest validation possible, theorically.
If someone wants to commit a game, he first enters it locally on his
personal PC, then commit when he is sure of it. If a source is unreliable,
the person owning the source will have to check the status by himself before
commiting. It is like a CVS repository : you only commit when you think code
is "good enough" (which does not prevent modifs later if necessary).
>
> For an illustration of what I am saying, you can take almost any
> nationality base, (XYZ)-base. Their author do monumental jobs. But the
> result is difficult to import into a refdb, since the data gets corrected
> time after time. I am having a hard time telling the Canadian manager which
> games are mine, and I reappear under the many bogus names I would like to
> correct time after time. I just stopped bothering after two times, but
> suppose I get back at him. He needs to correct by hand. How will these
> corrections be transported to CentriScid?
First commit what is "good enough", and leave the rest aside. Then admit
corrections if necessary (maybe versioning could help, or enter PGN games in
CVS, with many files and generate a DB from them ?)
Pascal
-------------------------------------------------------------------------
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
