[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Mon, Jan 12, 2009 at 01:36:56PM +0100, Simon Paillard wrote:
> On Mon, Jan 12, 2009 at 01:01:22PM +0100, Jens Seidel wrote:
> > On Mon, Jan 12, 2009 at 11:44:10AM +0100, Simon Paillard wrote:
> > > 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).
> We can see from build logs on www-master that the PO file is correctly

s/PO/SGML resp. DocBook XML/

> generated. (see attached the part specific to ro, ru, pt).

You're right.
> What do I miss ? (maybe backported po4a on www-master ?)

Yes, the installed version of po4a is probably >= 0.34-1.

I also checked that po4a-translate is indeed called (wouldn't be strictly
necessary if the generated and committed SGML/DBK files had a more recent time
> > > 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.
> If the SGML are removed from the SVN, there would be no risk of
> conflict.

With a recent version of Subversion (v1.6? maybe even 1.5) this will result in a tree
conflict (but no file conflict)! If a working copy contains local changes and
the corresponding files gets deleted in the repository "svn update" will result
in a conflict to avoid that these changes get lost.

But with access to the working copy this can be easily avoided.
> > > 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 ...
> No commit since 11 months. I've asked DSA whether the repository is set read-only or not.

Thanks for checking and your other tasks!


Reply to: