Re: commit files with the web interface

> I think that this system should use Joe's account (imaginary), if he has > one, but if he has no cvs account, then it should be committed with a > default translation group account. It is important to keep as much > information in the CVS logs as possible, so cvs commits should reflect > the user who changed the file. OK, I'm gonna do this. I will let the admin to add new users without CVS account. Those users will commit with a default account. Later, if they want to continue translating, encurage them to get a CVS account. > This is important, because usual CVS users will still do translations. > Also it is important for this system to handle colissions. It is not at > all sure that the cronjob will be able to commit the changes, if one CVS > user changes the file between the moment someone edits it in the online > app, and the cron runs. Therefore I would vote for immediate commits. > Also if this app would use cron, then it should handle the problem of > multiple change requests regarding the same file in the scope of the > application itself. Imagine that it commits the first change, then it > will not be possible to committ the second change, because it does not > contain the previous change (it is not updated). So it seems to me that > everything stands behind immediate commits. > > Goba Lets try with imediate commits. The cron job will only be used to checkout and update the db. One more thing: I was thinking in not translating the whole file at once. I'll explain: The script would parse the file and return a couple of senteces, only. The user would translate them and then they would go to the db. Then he would receive a couple of more sentences. I think this way is better, because you may translate only half file a day and the user wouldn't need to scroll up and down to translate. What do you think about this? Nuno