XPost: linux.debian.bugs.dist

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


IyEvdXNyL2Jpbi9lbnYgcGVybAoKdXNlIHdhcm5pbmdzOwp1c2UgYXV0b2RpZTsKdXNlIHN0cmlj dDsKCnByaW50ICJSdW5uaW5nIHVwZGF0ZSBob29rLi4uXG4iOwoKIyBIb29rIHRha2UgdGhyZWUg cGFyYW1ldGVyczogdGhlIG5hbWUgb2YgcmVmIHRvIHVwZGF0ZSwgb2xkIG9iamVjdCBuYW1lLCBu ZXcgb2JqZWN0IG5hbWUKbXkgKCRyZWZuYW1lLCAkb2xkLCAkbmV3KSA9IEBBUkdWOwoKIyBDaGVj ayB0aGF0IHdlIGFyZSBnb2luZyB0byB1cGRhdGUgcmVmL2hlYWRzL21hc3RlcgppZiAoJHJlZm5h bWUgZXEgJ3JlZnMvaGVhZHMvbWFzdGVyJykgewogICAgcHJpbnQgIlVwZGF0ZSBmb3IgJHJlZm5h bWVcbiI7CiAgICBwcmludCAiT0xEIGlzOiAkb2xkXG4iOwogICAgcHJpbnQgIk5FVyBpczogJG5l d1xuIjsKICAgICMgR2V0IGEgbGlzdCBvZiBjb21taXQgaWRzIGZyb20gJG9sZCB0byAkbmV3CiAg ICBjaG9tcChteSBAcmV2aXNpb25zID0gYGdpdCByZXYtbGlzdCAtLXJldmVyc2UgJG9sZC4uJG5l d2ApOwogICAgIyBJdGVyYXRlIHRocm91Z2ggYSBsaXN0IG9mIGNvbW1pdCBpZHMKICAgIGZvcmVh Y2ggKEByZXZpc2lvbnMpIHsKICAgICAgICBwcmludCgiQ1VSUkVOVDogJF9cbiIpOwogICAgICAg ICMgR2V0IGEgcGFyZW50IGNvbW1pdCBpZCBmb3IgdGhlICRfCiAgICAgICAgY2hvbXAobXkgJHBh cmVudCA9IChzcGxpdCAnICcsIGBnaXQgcmV2LWxpc3QgLS1wYXJlbnRzIC1uIDEgJF9gKVstMV0p OwogICAgICAgIHByaW50ICJQQVJFTlQ6ICRwYXJlbnRcbiI7CiAgICAgICAgIyBHZXQgYSBsaXN0 IG9mIGZpbGVzIGNoYW5nZWQgYmV0d2VlbiAkcGFyZW50IGFuZCAkXwogICAgICAgIGNob21wKG15 IEBjaGFuZ2VkX2ZpbGVzID0gYGdpdCBsb2cgLS1wcmV0dHk9XCJmb3JtYXQ6XCIgLS1uYW1lLW9u bHkgJHBhcmVudC4uJF9gKTsKICAgICAgICBwcmludCAiQ0hBTkdFRCBGSUxFUzogQGNoYW5nZWRf ZmlsZXNcbiI7CiAgICB9Cn0gZWxzZSB7CiAgICAjIEV4aXQgd2l0aCBub24temVybyB2YWx1ZSwg c28gcHVzaCBpcyByZWplY3RlZAogICAgZXhpdCAxOwp9Cg==

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)