Hi, I was playing with git hooks and realized that they could be used in migration of the Debian website content from CVS to git and saving CVS-style translation versions (even throw away "1." part from 1.x and keep just x). I guess this will make the migration for translators easier and will not require to completely rewrite translation check scripts (although some changes will be needed). Let's store CVS-style version of every translatable file somewhere (in file, database, or another VCS, "db" hereafter). When someone pushes changes to the repository these changes are checked with git hook to fetch a list of changed files. I propose to use update hook, because (1) it get ref name to update, old and new object names as parameters, (2) git will accept push only in case when update hook returns 0. The (2) is important because we don't want to accept changes which are not reflected in db. I've wrote some skeletion script, please find it attached. All prints there are just for debugging purposes, and output is forwarded to git send-pack, so user will see it. Currently, it doesn't support merges, so only one parent commit for a given commit. Say the last commit on the server is eab5, and there are two file, aaa (version 1.2) and bbb (version 1.7). Someone makes three commits, f3ea (aaa changed), f2e6 (bbb changed), and d4e3 (both aaa and bbb changed), and pushes them to the server. The script fetches a list of new commits (f3ea, f2e6, d4e3) starting from the already known commit (eab5, not included) to the last new commit (d4e3, included), and iterates through the list. Since we have three commits there will be three iterations, each will produce a list of changed files. That is, we will get three lists: (aaa), (bbb), (aaa, bbb). What follows will depend on design details. I can see two possible ways: 1. Update db as follows: aaa=1.4, bbb=1.8 (one version bump per commit) 2. Update db as follows: aaa=1.3, bbb=1.8 (one cumulitive version bump per file for all commits) I'm not sure which way is better. We could also store not just the current version, but rather version history with commit ids corresponding to each version. I don't think I ever saw reverts in website content CVS, but guess it also should be taken into account (and it will require some additional work). I agree that it may require a lot of work, but still it is an additional alternative to consider. I'd say that gettext and po4a are good candidates, but there are some particular shortcomings already mentioned in the wiki. Cheers! Lev Lamberov
Attachment:
update
Description: update