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.
>>
>
>

Reply via email to