Hi BB, No problem. No reason for me whatever to take offense. I was out anyway. Using the word could suggest a possibility. Below, you nicely reiterated why rcs, et al, is a poor choice, which I did discuss, along the similar view point as yours. As to my approach I did mention in earlier post that I would take a database based SYSTEM approach. Though I used the term database system. We agree that whatever system/design is used it should not STORE verbatim copies of things that do not change. Actually, that is what rcs et al. do. They track changes. Quite a lot of mantra in them. As to your approach not scaling well, well you look at the system for a single book system! What about the site offering up the books, following the workflow, and last but not least eventually offering finished books. The poor administrators of that site. To make it short I thinking on a far larger scale and a systematic approach. What do you do if a user wants to start with a particular version that another started because the work that was done was not that good (for whatever reason). Sorry, that I am not more concrete or can give a more detailed system, but if I took the time tp work things out further I could just as well design and implement the whole system, which I do not have the time to do. regards Keith. Am 28.10.2011 um 18:12 schrieb Bowerbird@aol.com:

keith said:

...

Hi BB, You ought to use your brain!!

i'm sorry, keith. are you feeling left out? i didn't mean to ignore you. it's just that all these people sprung from the woodwork so i got busy responding to their nonsense.

but you're right, i shouldn't ignore you. you are a regular contributor here, and it's not right to make you wait on them.

kind of like how the quiet behaving kids lose the teacher's attention whenever the troublemakers decide to act out again...

not that i'm the "teacher" here.

i might be pedantic, but i'm no teacher...

so i'm gonna handle you _first_ this morning.

...

1) I NEVER said that I agreed with the use of a revision control system!

well, you described some complications with such an approach, to be sure, but you also prefaced all of them by saying:

...

A revision control system could work.

so it's pretty easy to view what you said as showing how to make such a system work.

thus it's kind of a mixed bag about whether you "agreed" with what lee was proposing...

and lee was most definitely proposing that "a revision control system" be used. indeed, he used that phrase, _word-for-word_, and he even mentioned r.c.s. and c.v.s. by name.

and, as shown in the quote from you above, you used that exact same phrase yourself...

i mean, if you tell me now that you do _not_ agree with it, i believe you. but from what you wrote in your post, that is very unclear.

...

I did say in is a possibility, not that I agree with it.

you didn't really just call it a "possibility" -- that word didn't appear in your post -- you said _explicitly_ that it "could work"...

if you want to scale that back a bit now, i can accept that. but at the same time, your new position isn't too much better.

so you now call it "a possibility" to use a revision control system (e.g., c.v.s.).

well, of course, one _could_ certainly use a revision control system for digitization being performed in a collaborative way...

but...

i'd say it's such a stupid idea that to even consider it "a possibility" is a stupid path.

i would rule it out, completely, in 1 second. (surely an idea needs more viability than a 1-second lifespan to be "a possibility".)

remember, the idea (which i say is clearly _stupid_) is to put hundreds and hundreds of files -- most of which _never_ change -- in a type of system that's perversely complex, a system designed to keep track of revisions.

and even the files that _do_ change are just tiny little text-files, with a couple dozen lines, and most changes are to words in those lines, the kind of edits that do not need (or want!) the dense branching and reversion features that revision control systems are devised for.

and "hundreds and hundreds of files" means _for_a_single_book_, and we are discussing doing quite literally _thousands_ of books...

so you'd be putting _millions_of_files_ into your very complex revision control system.

so if there is any system that "doesn't scale", i would say that it would be _this_ system...

i bet the _vast_majority_ of d.p. volunteers have _never_ used a revision control system.

heck, i bet a majority of them couldn't even tell you what a revision control system _is_.

and if you're gonna depend on volunteers to digitize your books, you've got to view the volunteers at distributed proofreaders as the type of people you will be getting, since they are the only known people on the planet who've stepped up to volunteer.

so, in a nutshell, bluntly, if you're counting on "a revision control system", you will fail.

because those systems are very complex.

so that idea is just ridiculous on its face... for the many reasons which i've described. and to say _anything_else_ is just _stupid_.

but hey, i'd love to hear counterarguments.

oh wait, you know what? i already have a system that i've written that does the job, simply and efficiently. and it ain't broke, so i have no need to "fix" it, so unless you have a working system already in place that demonstrates what _you_ suggest, then we don't even need to discuss it, ok?

thanks.

...

As a matter of fact I suggest using a different approach.

is this a new suggestion you're now making?

because i don't recall you describing it before.

in fact, i note that you don't say -- even now -- what this "different approach" is...

...

2) I said your approach is workable, but not scale.

sorry, keith, but i can't humor you any more.

because i already described how it _would_ scale -- that being the main point -- and i'm not going to repeat the arguments just because you didn't read them the first time.

...

You talk about a book and a few people working on it.

i talk about how one script handles one book, and the dozen people who will do work on it...

at maximum, since if you have more than that, all they're doing is getting in each other's way.

in practice, you could have a hundred people operating on it, and the script could handle it, but that's not the optimal way to do this job...

and yes, the point is that one script can handle the task of one book with the greatest of ease...

...

What happens to your system with thousands of books and lot more people.

you seem to have missed the whole point, keith.

which is that the system scales easily by having each book in a folder handled by its own script.

so to deal with thousands of books, you will create thousands of copies of the script, with each copy handling one book, with great ease.

you could have _a_million_ books, and the mantra is the same -- one script per book, handling the task with the greatest of ease.

-bowerbird _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d