Hi, The move issue are shared by both -doc and -www. Really, I think if we find a good way to move debian-www system, we will follow the same path to move debian-doc. My understanding is that the moving to alioth can be done anytime if web page building infrastructure is also updated by someone with access to www.debian.org. One way to avoid www access issue is to follow how d-i folks work around the problem. I vaguely remember Frans told me how he worked around the www.debian.org access issue once but I lost the message and memory. (I think he build it on alioth and www copies the built web page or so.) Once we find out good web page building scheme, we should move to alioth CVS first. This move is snap. tar -> scp -> untar. No adjustment needed. Just account generation for guests. Then we all discuss which VCS to use. It could be mix of them for each portion as long as build script are accessible by us to update it. As for git, let me share Raphael's comment on -www too. I also have to say that actual git conversion may suffer funny issue. (This could be encoding issue). See below for my trial. On Sun, Aug 19, 2007 at 11:43:47AM +0200, Raphael Hertzog wrote: > On Sun, 19 Aug 2007, Osamu Aoki wrote: > > > Alioth also supports CVS, so if you want to keep CVS, you can do that as > > > well. But I encourage you to switch to something else and I can help you to > > > convert the repository if needed. > > > > I think since DDP uses "$Revision: $" thing quite a bit as the ways to > > keep track version difference, I think the only practical choice is > > keeping CVS or moving to Subversion repository. (Not git nor monotone > > nor hg.) > > Honestly, I'd expect to switch to subversion since it's very easy to > switch to for people who are used to CVS. > > However, technically speaking I'm sure there are solutions to track > translations automatically with other VCS. At least with git where most > low level commands are usable from scripts. One can extract the last > commit that modified a file with a command like this one: > $ git-rev-list -n 1 HEAD -- thefile > 54bb0defc14d937ed2bfd93a705cb6892d3766dd > > And if you have a "reference" commit you can do this command to find out > all the commits that changed the file since that commit: > $ git-rev-list HEAD ^c6549f3c0c63e7c2c178200b40dac167efe53d46 -- thefile > 54bb0defc14d937ed2bfd93a705cb6892d3766dd > e818d3b0cfc363ee7624c7a61f3e07f837312ad1 > 5371b8082c6e7ecd9a71c37f92442eaeebe33ebc > d031120a39fbbb390363b9515152362e7951790c > 2d0f04e918ca4fc74bd14f536acfc96efdcdc4f3 > > If the output is non-empty, then you know the translation is outdated. I think this replies some of the issues raised on debian-www for transition thus I am CCing this. So git can be used with minor adjustment in theory. -------------- FYI: git move was not so trivial... Just for the record, DDP CVS is big (but not as big as WWW) osamu@snoopy:~/Desktop/src/ddp$ ls -lh debian-doc-cvs.* -rw-r--r-- 1 osamu osamu 63M 2007-08-20 19:12 debian-doc-cvs.tar -rw-r--r-- 1 osamu osamu 20M 2007-08-20 19:09 debian-doc-cvs.tar.gz Hmmm... it is quite easy, if we just move CVS. * announce in advance. * set all repositiry to read only on a agreed day to be safe. * tar -> scp -> untar * everyone check out from new place. If we do, I will even replace quick-reference tree with upstream one to make it really consistent. Although git in CVS like usage may be fast and nice, my trial of making git-cvsimport failed as follows for ddp. ... Fetching manuals.sgml/maint-guide/maint-guide.fr.sgml v 1.1 New manuals.sgml/maint-guide/maint-guide.fr.sgml: 59199 bytes Tree ID 6e794a1b9c332327c8b7372067b193cd674f3f8d Parent ID 3446641197000756757ba806242004dc09e7729d Committed patch 270 (origin +0000 1999-08-30 22:42:24) Warning: commit message does not conform to UTF-8. -- Fetching manuals.sgml/developers-reference/developers-reference.sgml v 1.46 Update manuals.sgml/developers-reference/developers-reference.sgml: 95135 bytes Tree ID e56f47659df73feee5ac1d0c421b0ba4214cee50 Parent ID b953774de9aa8c687a94cb97bda52b95f596bf3c Committed patch 519 (origin +0000 2000-12-19 00:04:59) Warning: commit message does not conform to UTF-8. -- Fetching manuals.sgml/faq/debian-faq.ru.sgml v 1.2 Update manuals.sgml/faq/debian-faq.ru.sgml: 1605 bytes Tree ID 25b86338bbc1c27b800883169186fda39691e17b Parent ID 6cd7336f4ff0b196e09e6bd628dc4cb4b7c2aa76 Committed patch 569 (origin +0000 2001-03-07 05:26:37) Warning: commit message does not conform to UTF-8. -- Fetching manuals.sgml/securing-howto/COMO-Asegurar-Debian.sgml v 1.1 New manuals.sgml/securing-howto/COMO-Asegurar-Debian.sgml: 51007 bytes Tree ID 50a90e2b298a4df8e1a4baae8a1debc7a02f534d Parent ID 04118c41f05619461959135cfece7e06b1e5be66 Committed patch 614 (origin +0000 2001-04-11 09:57:18) Warning: commit message does not conform to UTF-8. ... Parent ID 1ffb0b80d94db5d2284c3c09e73f3a12eb02e839 Committed patch 672 (origin +0000 2001-08-01 12:33:04) Commit ID e1f23c722d5c378bb8f26dd095a139a2b8a004bc Fetching manuals.sgml/apt-howto/Makefile v 1.1 New manuals.sgml/apt-howto/Makefile: 1190 bytes Fetching manuals.sgml/apt-howto/apt-howto-en.sgml v 1.1 New manuals.sgml/apt-howto/apt-howto-en.sgml: 41977 bytes Fetching manuals.sgml/apt-howto/apt-howto-pt_BR.sgml v 1.1 New manuals.sgml/apt-howto/apt-howto-pt_BR.sgml: 41759 bytes Tree ID 516093d4b6ab0f528af31ae735857cf5f6f6e7c5 Parent ID e1f23c722d5c378bb8f26dd095a139a2b8a004bc Committed patch 673 (origin +0000 2001-08-11 05:16:27) fatal: You don't exist. Go away! Use of uninitialized value in chomp at /usr/bin/git-cvsimport line 758. Use of uninitialized value in pattern match (m//) at /usr/bin/git-cvsimport line 519. Use of uninitialized value in concatenation (.) or string at /usr/bin/git-cvsimport line 759. Cannot get commit id (): (Well, this is from alioth. It fails earlier from my home since my ssh connection is reset by peer.) I do not know the cause (may be corrupt data around 2001-08 is causing problem. So although in theory, it is trivial to move archive, it is not so easy. I did not do the same for www but they may have suffered the same FS corruption back then. (This may be some limitation due to git-cvsimport) Osamu
Attachment:
signature.asc
Description: Digital signature