Hi Mikhail, Thanks for your hint. I checked /usr/lib/python2.5/site-packages/hgext/win32ext.py of my cygwin 1.5 and found no forbidcrlf() function defined. Using a cygwin 1.7 helped me to commit. And then I found the files left behind by TortoiseHg simply had their mode changed this time..
Till now the only files marked as uncommitted are external or generated: ############ output ############## $ hg status ? external/dbghelp/DbgHelp.Dll ? external/gdiplus/gdiplus.dll ? external/msi/instmsia.exe ? external/msi/instmsiw.exe ? external/msvcp71/msvcr71.dll ? external/msvcp80/msvcp80.dll ? external/msvcp80/msvcr80.dll ? external/msvcp90/Microsoft.VC90.CRT.manifest ? external/msvcp90/msvcm90.dll ? external/msvcp90/msvcp90.dll ? external/msvcp90/msvcr90.dll ? external/unicows/unicows.dll ? guw/guw.exe ? moz/zipped/WNTMSCIinc.zip ? moz/zipped/WNTMSCIlib.zip ? moz/zipped/WNTMSCIruntime.zip ? winenv.set ? winenv.set.sh ############ output ############## Should I add these files to .hgignore to let the merge go ahead? However, will that affect the repositories of other developers? Best Regards, Felix. On Fri, Jul 30, 2010 at 7:51 PM, Mikhail Voytenko < mikhail.voyte...@oracle.com> wrote: > Hi Felix, > > The message > > > abort: pretxncommit.crlf hook is invalid ("hgext.win32text.forbidcrlf" > is not defined) > let me think that the hoot you are trying to use is probably just not > installed. Could you please check your hg-installation to be sure that the > hook is correctly installed. > > Best regards, > Mikhail. > > > On 07/30/10 12:10, Zhang Xiaofei wrote: > > Hi MIkhail, > > You are right, after last time I pushed to hg I rolled back to clean > DEV300_m83 to restart the replacing to avoid messing up. So I guess a merge > is necessary. But I'm getting new problems now: > > I did "hg status" and the output is below: > ############ output ############## > $ hg status > M svl/source/items/rngitem_inc.cxx > M tools/inc/tools/globname.hxx > M tools/inc/tools/inetmime.hxx > M tools/inc/tools/string.hxx > M tools/source/fsys/comdep.hxx > M tools/source/fsys/dirent.cxx > M tools/source/fsys/filecopy.cxx > M tools/source/fsys/fstat.cxx > M tools/source/fsys/tdir.cxx > M tools/source/fsys/wldcrd.cxx > M tools/source/fsys/wntmsc.cxx > M tools/source/fsys/wntmsc.hxx > M tools/source/memtools/contnr.cxx > M tools/source/memtools/mempool.cxx > M tools/source/memtools/multisel.cxx > M tools/source/memtools/table.cxx > M tools/source/memtools/unqidx.cxx > M tools/source/stream/stream.cxx > M unotools/inc/unotools/lingucfg.hxx > M unotools/inc/unotools/syslocaleoptions.hxx > M unotools/source/config/lingucfg.cxx > M unotools/source/config/syslocaleoptions.cxx > ? external/dbghelp/DbgHelp.Dll > ? external/gdiplus/gdiplus.dll > ? external/msi/instmsia.exe > ? external/msi/instmsiw.exe > ? external/msvcp71/msvcr71.dll > ? external/msvcp80/msvcp80.dll > ? external/msvcp80/msvcr80.dll > ? external/msvcp90/Microsoft.VC90.CRT.manifest > ? external/msvcp90/msvcm90.dll > ? external/msvcp90/msvcp90.dll > ? external/msvcp90/msvcr90.dll > ? external/unicows/unicows.dll > ? guw/guw.exe > ? k.sh > ? moz/zipped/WNTMSCIinc.zip > ? moz/zipped/WNTMSCIlib.zip > ? moz/zipped/WNTMSCIruntime.zip > ? tools/source/stream/stream.cxx.orig > ? winenv.set > ? winenv.set.sh > ############ output ############## > > This is weird as I have already committed those "M" marked files along > with hundreds of other files using TortoiseHg, and the clone appears > completely committed in TortoiseHg now (reading the content of files proves > that too). > As a consequence, when I did "hg merge" I got this: > ############ output ############## > $ hg merge > abort: outstanding uncommitted changes > ############ output ############## > > And when I tried to commit those files by commands, I got another > problem: > ############ output ############## > $ hg commit -m"removetooltypes01: #i112600#: TortoiseHg failed to commit > these > files" svl/source/items/rngitem_inc.cxx tools/inc/tools/globname.hxx > tools/inc/ > tools/inetmime.hxx tools/inc/tools/string.hxx tools/source/fsys/comdep.hxx > tool > s/source/fsys/dirent.cxx tools/source/fsys/filecopy.cxx > tools/source/fsys/fstat > .cxx tools/source/fsys/tdir.cxx tools/source/fsys/wldcrd.cxx > tools/source/fsys/ > wntmsc.cxx tools/source/fsys/wntmsc.hxx tools/source/memtools/contnr.cxx > tools/ > source/memtools/mempool.cxx tools/source/memtools/multisel.cxx > tools/source/mem > tools/table.cxx tools/source/memtools/unqidx.cxx > tools/source/stream/stream.cxx > unotools/inc/unotools/lingucfg.hxx > unotools/inc/unotools/syslocaleoptions.hxx > unotools/source/config/lingucfg.cxx > unotools/source/config/syslocaleoptions.cxx > abort: pretxncommit.crlf hook is invalid ("hgext.win32text.forbidcrlf" is > not de > fined) > transaction abort! > rollback completed > ############ output ############## > > I suppose it has something to do with my .hgrc file, which looks like > this: > ############ .hgrc ############## > [ui] > # The user name will appear as author tag on commits. > username=Zhang Xiaofei <zhangxiao...@openoffice.org> > # Domain developers only: OOo ssh authentication for pushing > # to 'outgoing' repositories. > ssh=ssh -C -v -i /home/zxf/.ssh/id_dsa > > [extensions] > # Required if 'cws fetch' is used to fetch a CWS. > hgext.mq= > # Enables the bundled win32text extension. See [hooks] section. > hgext.win32text= > > [hooks] > # Reject commits which would introduce windows-style CR/LF. > # Enabling this hook is strongly suggested for OOo development. > pretxncommit.crlf = python:hgext.win32text.forbidcrlf > ############ .hgrc ############## > > Could you have a look and see if I missed something please? > > Thanks and Best Regards, > Felix. > > > On Thu, Jul 29, 2010 at 6:37 PM, Mikhail Voytenko < > mikhail.voyte...@oracle.com> wrote: > >> Hi Felix, >> >> I would suggest to do "hg status" to see which files were changed, and >> commit them explicitly if the changes are OK. After that please try "hg >> merge". >> >> By the way, the situation looks to be quite strange, since you are the >> only one who works on this cws. So there should be nothing to "pull", if you >> work from the same hg-repository always. And there should be no additional >> heads. >> Could you please do "hg heads" and send the output. >> >> Best regards, >> Mikhail. >> > >