Last modified: 2011-05-31 03:46:35 UTC
A recent discussion was started about Language/Message updates, which disturbed developing and broke commits due to conflicts, see http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/53848 My ad-hoc proposal: "prevent LU update" file as a flag to prevent from unexpected languages/messages during agile development. The updaters should respect a kind of PREVENT-UPDATE-UNTIL-<TIMESTAMP-UTC> file flag in the language and message directories of the core and the extensions. Tom
(In reply to comment #0) > My ad-hoc proposal: "prevent LU update" file as a flag to prevent from > unexpected languages/messages during agile development. > > The updaters should respect a kind of PREVENT-UPDATE-UNTIL-<TIMESTAMP-UTC> file > flag in the language and message directories of the core and the extensions. The flag is intended to be used by developers who wish - for a limited certain time - to stop the updates of the language/messages files. The timeout file flag should always bear the expiry date in its filename, so that an automatic cleanup (by a cron bot) would become possible.
I do not understand what problem this bug is about. I don't understand how LocalisationUpdate disturbs development or breaks commits.
(In reply to comment #2) > I do not understand what problem this bug is about. I don't understand how > LocalisationUpdate disturbs development or breaks commits. Ashar, Raimond and also I had commit conflicts in the past two weeks, which required at least work at Raimond's side (example: http://svn.wikimedia.org/viewvc/mediawiki?view=revision&revision=88351 on Tue May 17 20:54:10 2011 UTC. ) So this can happen, nobody wants it to happen of course)
A similar, positive, "allow" flag is prosed (per-directory) now: - TRIGGER-TRANSLATION-UPDATE-SINCE-<TIMESTAMP> Usually, if a developer needs an update, and those wjho know how it works would send you or Raymond a mail. I suggest this here as a correspondent flag to - PREVENT-LANGUAGE/MESSAGE-UPDATES-UNTIL-<TIMESTAMP> flag.
So this isn't about Localisation Update after all. The obvious fix is for everyone to reload all files in their editor after they do svn up, or open the files after doing svn up. It should be easy to catch that kind of mistakes by running svn diff before commit like everyone should do :)
(In reply to comment #5) > So this isn't about Localisation Update after all. The obvious fix is for > everyone to reload all files in their editor after they do svn up, or open the > files after doing svn up. Another problem solved by Emacs: "File has been modified since you loaded, really save?" But, yes, I would rather encourage sane development practices (a social fix) than what looks like a fragile, problematic technical fix.
(In reply to comment #6) > Another problem solved by Emacs: "File has been modified since you loaded, > really save?" I prefer the butterfly method over emacs tbh
/me doesn't really like this idea. Sounds like a re-invention of svn lock in a fragile way (not that we use svn lock, but sounds pretty identical in function). But really, just being careful sounds like the best solution.
(In reply to comment #8) > /me doesn't really like this idea. Sounds like a re-invention of svn lock in a > fragile way (not that we use svn lock, but sounds pretty identical in > function). > > But really, just being careful sounds like the best solution. I'm WONTFIXing per this and pretty much everything above.
