Re: build of etch release-notes from svn, conflicts with sgml vs po: ro, pt, ru

[Jens Seidel <jensseidel@users.sf.net>]

On Mon, Jan 12, 2009 at 11:44:10AM +0100, Simon Paillard wrote:
> Dear russian, portuguese and romanian l10n team,

I dropped these teams from CC:.
 
> During the build of etch release notes, it appears that some of your
> translations are performered in the po files, some other in the SGML.
> 
> Please see below what you should perform to update the po file before
> the SGML can be safely removed.

In the past it was not possible to remove the (generated SGML) files because
of errors in the old build infrastructure. The Makefile still contains my
comment:
# TODO: Once #477458 is fixed in stable remove all committed sgml files
# which are generated from a PO file (was a workaround for old po4a).
 
> On Mon, Jan 12, 2009 at 10:13:26AM +0100, Jens Seidel wrote:
> > Thanks. So it is probably OK to work in tags/ to fix remaining minor issues?
> > Normally such work happens on a branch.
> 
> Anyway SVN doesn't make the difference between a tag and a
> branch.

Right :-)
 
> > But as work on the Etch version stopped there should indeed no problem
> > with it.
> 
> As spotted by Rhonda, some sgml files are stored in the (etch) SVN
> together with their po source, as a consequence :
> $ svn status | grep -v ^?
>  M      ro/release-notes.ro.sgml
>  M      pt/release-notes.pt.sgml
>  M      ru/release-notes.ru.sgml

That's the status in your local working copy, not on the build host where only
a very restricted set of people has access to, right?
 
> Unfortunately, they cannot be removed straight away from the SVN,
> because the translations are not consistent in PO and SGML :

Later removal of files with local modifications should also cause a svn (tree)
conflict.
 
> Then update the PO so that no translated string gets lost when the SGML
> will be removed from the SVN.
> 
> The right place to change the po is :
> svn://svn.debian.org/ddp/manuals/tags/release-notes/etch

This remembers me that it would be a good idea to verify that no one works
any longer on the files in CVS ...

Jens