[boost] Re: CVS status
On Thu, 8 May 2003 05:20:11 -0500, Aleksey Gurtovoy [EMAIL PROTECTED] wrote: I just restored the lost revisions for these three headers: boost/config/platform/win32.hpp boost/config/stdlib/stlport.hpp boost/filesystem/convenience.hpp Thanks Aleksey. I was particularly interested to stlport.hpp (incidentally: though that doesn't affect the good functioning of the file, the space between # and endif: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/boost/config/stdlib/stlport.hpp.diff?r1=1.19r2=1.20 surprises me a bit. Don't call me pedantic, but I'm a curious one :-) I had seen the colored diff before and didn't notice it. Note that without the space the line shown in green is, I guess, the following one, so that's unlikely to get unnoticed when you visually try to match the #if-s) and, comparing what is probably the most recent before-the-disk-crash CVS snapshot to the current CVS state, it seems that collectively we've been able to restore everything. Still, if we have resources for that, may be it's worthy to set up a backup job somewhere to copy everything off-site, nightly or so - we might not be so lucky next time. I'm not against that. However, as far as I've understood from the mail that Beman quoted, the sourcefourge people make daily backups anyway. I think what we should have (ideally) is not a daily backup, but a newest version backup (if nothing else, the daily and nightly concepts fail miserably for boost, since we have developers in many different timezones). I drop an idea: suppose that when there's a new commit the CVS informs, via e-mail, the penultimate people that had done a commit. This way I (the generic developer) can do the following: before doing any commit check out the whole repository (in order to have the newest state of everything), then _until I receive the informative mail_, I do keep my copy. When I receive the mail I know that the duty to keep the files is up to someone else. Of course that doesn't protect against failures of the last committor machine, but... As a further precaution we could advice for keeping a fresh checkout for at least one day, regardless of informative mails (provided that we can setup something similar). Thoughts? Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS status
Gennaro Prota wrote: I drop an idea: suppose that when there's a new commit the CVS informs, via e-mail, the penultimate people that had done a commit. This way I (the generic developer) can do the following: before doing any commit check out the whole repository (in order to have the newest state of everything), then _until I receive the informative mail_, I do keep my copy. When I receive the mail I know that the duty to keep the files is up to someone else. Of course that doesn't protect against failures of the last committor machine, but... As a further precaution we could advice for keeping a fresh checkout for at least one day, regardless of informative mails (provided that we can setup something similar). Thoughts? I think this is a bit more complicated that it should be. Why don't just create boost-wide commit emails mailing list? All changes will be reflected in archives, so in case of emergency you'll have all the data to replay missing commits. Of course, what happens if ml archive is destroyed too as the same time... but that's less likely. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: CVS status
Gennaro Prota wrote: I think this is a bit more complicated that it should be. Why don't just create boost-wide commit emails mailing list? Off-hand _this one_ seems more complicated, because it involves more people than necessary and forces to keep the diffs (though just for, say, a couple of days - longer than that, we have the daily backups). Actually, it does not involve any people: just create a new list on sourceforge and set up commit emails. Unless disk crashes, nobody is forced to even look at this list. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: CVS status
... various backup suggestions SourceForge already makes the entire Boost CVS tarball available every night, and several Boosters download it daily. (At least I hope they do - I have no way of telling if they are still running their cron jobs.) That is supposed to protect us from total failure, such as SourceForge going bankrupt and shutting down unexpectedly. But it isn't clear what the best procedure is to protect against partial failure - it seemed easier just to restore file-by-file in this particular case. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: CVS status
Beman Dawes wrote: ... various backup suggestions SourceForge already makes the entire Boost CVS tarball available every night, and several Boosters download it daily. Oh, good. There is no such thing as too much backup. (At least I hope they do - I have no way of telling if they are still running their cron jobs.) That is supposed to protect us from total failure, such as SourceForge going bankrupt and shutting down unexpectedly. But it isn't clear what the best procedure is to protect against partial failure - it seemed easier just to restore file-by-file in this particular case. Sure, if the files content indeed makes sense. I would characterize our case as malfunctioning with the possible result of the bogus content; in this situation, plain content backup, whether it's intentional or accidental, tarball or separate files, is not a reliable source to restore from. We just happened to be lucky this time (if John will be able to restore his branch). I think Vladimir's suggestion makes sense and is worth doing. It covers what plain backups cannot, and costs nothing in terms of maintenance. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
