Re: [fossil-users] Maybe a bug in sync
On Aug 17, 2011, at 09:09 , Eric wrote: That is another DVCS - Veracity(http://veracity-scm.com). But then you say that there's this other DVCS with a different design philosophy and a different internal structure Don't know about internals, but on the first look the design seems to be pretty similar... And extremally immature as of now: Veracity's current bug tracker really isn't designed for the needs of an open source project. We'll fix that eventually. Anyhow, it looks to me like Fossil plus Scrum support and file locks. Out of which only the second seems to be worth it in some corner cases. See here for explanation: http://veracity-scm.com/qa/questions/102/why-would-you-design-a-dvcs-in-2011-that-supports-file-locks-dvcs-are-meant-to-make-it-needless-to-worry-about-that Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
On Aug 17, 2011, at 19:14 , Tomek Kott wrote: All info about veracity aside...anyone have any idea why there doesn't seem to be an obvious error in the fossil sync, yet a file is not being synced? The httptrace doesn't indicate anything wrong (to my untrained eyes), but obviously doesn't include file content. Any ideas? Was anybody able to reproduce the problematic situation? I'm not even able to run .bat files, as I don't have a Windows instance handy... Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
Was anybody able to reproduce the problematic situation? I'm not even able to run .bat files, as I don't have a Windows instance handy... I haven't run the batch files either -- I'm just typing things in by hand (the same commands as if it were batch files). I can't reproduce the error either, and fossil doesn't seem to be throwing a fit over anything, and the only thing about the httptrace output that confirms the error is that there is no file information sent. As to why that would happen I don't know. Tomek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
Compare to veracity(http://veracity-scm.com): v_server.bat if exist D:\server rd /s /q D:\server md D:\server cd /d D:\server vv version @if errorlevel 1 goto :eof vv repo delete ops.server vv init ops.server @if errorlevel 1 goto :eof vv whoami --create Server @if errorlevel 1 goto :eof echo server0 server0.txt vv add server0.txt @if errorlevel 1 goto :eof vv commit --message server0 @if errorlevel 1 goto :eof vv serve --port 443 --public @if errorlevel 1 goto :eof v_server.txt Microsoft Windows XP [版本 5.1.2600] (C) 版权所有 1985-2001 Microsoft Corp. C:\Documents and Settings\Administratorv_server C:\Documents and Settings\Administratorif exist D:\server rd /s /q D:\server C:\Documents and Settings\Administratormd D:\server C:\Documents and Settings\Administratorcd /d D:\server D:\servervv version 1.0.0.10517 (f6ff5fc789) [32-bit] D:\servervv repo delete ops.server Deleting ops.server... Done. D:\servervv init ops.server D:\servervv whoami --create Server D:\serverecho server0 1server0.txt D:\servervv add server0.txt D:\servervv commit --message server0 revision: 2:eab6bb7fa81cf868370a0784c438a79107632a32 branch: master who: Server when: 2011/08/16 15:55:22.849 +0800 comment: server0 parent: 1:9636b1c7a7de89efa94d28d6f30b0ff0a417cbc1 D:\servervv serve --port 443 --public Serving unencrypted on port 443. v_client.bat if exist D:\client rd /s /q D:\client md D:\client cd /d D:\client vv version @if errorlevel 1 goto :eof vv repo delete ops.client vv clone http://%COMPUTERNAME%:443/repos/ops.server ops.client @if errorlevel 1 goto :eof vv checkout ops.client @if errorlevel 1 goto :eof vv whoami --create Client @if errorlevel 1 goto :eof echo client1 client1.txt vv add client1.txt @if errorlevel 1 goto :eof vv commit --message client1 @if errorlevel 1 goto :eof vv push @if errorlevel 1 goto :eof @echo. @echo Turn to server cd /d D:\server vv whoami Server @if errorlevel 1 goto :eof vv update @if errorlevel 1 goto :eof echo server1 server1.txt vv add server1.txt @if errorlevel 1 goto :eof vv commit --message server1 @if errorlevel 1 goto :eof @echo. @echo Turn back to client cd /d D:\client vv whoami Client @if errorlevel 1 goto :eof vv pull --update @if errorlevel 1 goto :eof fc /b server0.txt ..\server\server0.txt @if errorlevel 1 goto :eof fc /b client1.txt ..\server\client1.txt @if errorlevel 1 goto :eof fc /b server1.txt ..\server\server1.txt @if errorlevel 1 goto :eof vv history @if errorlevel 1 goto :eof v_client.txt Microsoft Windows XP [版本 5.1.2600] (C) 版权所有 1985-2001 Microsoft Corp. C:\Documents and Settings\Administratorv_client C:\Documents and Settings\Administratorif exist D:\client rd /s /q D:\client C:\Documents and Settings\Administratormd D:\client C:\Documents and Settings\Administratorcd /d D:\client D:\clientvv version 1.0.0.10517 (f6ff5fc789) [32-bit] D:\clientvv repo delete ops.client Deleting ops.client... Done. D:\clientvv clone http://Y00122496:443/repos/ops.server ops.client Downloading repository.. Done. Saving new repository... Done. Use 'vv checkout ops.client path' to get a working copy. D:\clientvv checkout ops.client D:\clientvv whoami --create Client D:\clientecho client1 1client1.txt D:\clientvv add client1.txt D:\clientvv commit --message client1 revision: 3:86012564129e408f05ca285022f1f1ea02fa02e4 branch: master who: Client when: 2011/08/16 15:55:55.052 +0800 comment: client1 parent: 2:eab6bb7fa81cf868370a0784c438a79107632a32 D:\clientvv push Pushing to http://Y00122496:443/repos/ops.server: Pushing... Done. Turn to server D:\clientcd /d D:\server D:\servervv whoami Server D:\servervv update D:\serverecho server1 1server1.txt D:\servervv add server1.txt D:\servervv commit --message server1 revision: 4:f34dca635cd1ddaae759488858ee316a0d849b9a branch: master who: Server when: 2011/08/16 15:56:09.662 +0800 comment: server1 parent: 3:86012564129e408f05ca285022f1f1ea02fa02e4 Turn back to client D:\servercd /d D:\client D:\clientvv whoami Client D:\clientvv pull --update Pulling from http://Y00122496:443/repos/ops.server: Pulling... Done. Updating... Done. D:\clientfc /b server0.txt ..\server\server0.txt 正在比较文件 server0.txt 和
Re: [fossil-users] Maybe a bug in sync
Perhaps someone with better experience at reading the httptrace options could chime in, since I'm not sure where the error is. Are there other debugging parameters available, either for the server or the sync function? For comparison, here are my http traces for the first sync. Notice, that I have two lines called file along with the content of the file in http-request-1.txt -- http-request-1.txt POST /xfer/xfer HTTP/1.0 Host: 127.0.0.1:8080 User-Agent: Fossil/1.19-[fca3073621] Content-Type: application/x-fossil-debug Content-Length: 932 login tkott 864612d373ba3887eb283f20f8d27b0d2c89617f ccf80014951c466686a9270e86d8a3a25fcb1dec pull 104247dc269453d32809ca3d60a0912a7650238e 63233558037844f3e9f0bea0fe3a5dcceba7b620 push 104247dc269453d32809ca3d60a0912a7650238e 63233558037844f3e9f0bea0fe3a5dcceba7b620 file c26bfac4c8e9145f53df06992380c1e7bc688f9e 9 client file 506593acfd700309d9a82e66c65f32a7b838d8e9 268 C client.txt D 2011-08-16T13:29:28.902 F client.txt c26bfac4c8e9145f53df06992380c1e7bc688f9e F server.txt acc8828b67a8289bec332ae9216b040b47303acc P e203bc4bd922ecede12b7276efadfb2c049b R 2fa786c44d14db93202e5825f6e901f3 U tkott Z 35a636b61a863b6a0d89d5dc3ae94ad6 igot ec02251bbe84371c253db885bcc56ccbb3a92769 igot acc8828b67a8289bec332ae9216b040b47303acc igot e203bc4bd922ecede12b7276efadfb2c049b igot c26bfac4c8e9145f53df06992380c1e7bc688f9e igot 506593acfd700309d9a82e66c65f32a7b838d8e9 reqconfig /shun # E76D917F6FCB07DE46C9E5CECAA1B93481BA21F5 -- http-reply-1.txt HTTP/1.0 200 OK Date: Tue, 16 Aug 2011 13:29:54 GMT Connection: close X-Frame-Options: DENY Cache-control: no-cache, no-store Content-Type: application/x-fossil-debug; charset=utf-8 Content-Length: 262 igot ec02251bbe84371c253db885bcc56ccbb3a92769 igot acc8828b67a8289bec332ae9216b040b47303acc igot e203bc4bd922ecede12b7276efadfb2c049b igot c26bfac4c8e9145f53df06992380c1e7bc688f9e igot 506593acfd700309d9a82e66c65f32a7b838d8e9 # timestamp 2011-08-16T13:29:54 One D:\clientfossil close ops D:\clientcd \ D:\client\http-request-1.txt POST /xfer/xfer HTTP/1.0 Host: y00122496:8080 User-Agent: Fossil/1.19-[fca3073621] Content-Type: application/x-fossil-debug Content-Length: 545 login y00122496 cc65e78b0068b497efe2f38334d8e4b1c8b88afe b6e932c2df283bf2aae2538ac1ceea16cfa68696 pull 1b9fc5d540f690029289a6de049cc10ccf00e76f b47f5b8291724ebbe9ca27bdf555367d5a308f1d push 1b9fc5d540f690029289a6de049cc10ccf00e76f b47f5b8291724ebbe9ca27bdf555367d5a308f1d igot a8407eb60d9c72630b93224f31bfc36a0f9d70de igot acc8828b67a8289bec332ae9216b040b47303acc igot 19d53dd50593b47cf6502018ac4f57a8407ddeec igot e0ed8945f6d2b387342051f102bb945eb8548828 igot 2059fac527a7d0c8b959afeb29e78d47cf57412a # E29855B4B0BD6BA536CE40EEE801C8156D4BD2AD D:\client\http-reply-1.txt HTTP/1.0 200 OK Date: Tue, 16 Aug 2011 08:26:15 GMT Connection: close X-Frame-Options: DENY Cache-control: no-cache, no-store Content-Type: application/x-fossil-debug; charset=utf-8 Content-Length: 356 gimme e0ed8945f6d2b387342051f102bb945eb8548828 gimme 2059fac527a7d0c8b959afeb29e78d47cf57412a igot a8407eb60d9c72630b93224f31bfc36a0f9d70de igot acc8828b67a8289bec332ae9216b040b47303acc igot 19d53dd50593b47cf6502018ac4f57a8407ddeec igot ac1098901ce48c9b1f06dc10fb31509153c42b02 igot 11060e36f3c43939f1b1cfb673ea589b1b2d3ddb # timestamp 2011-08-16T08:26:15 D:\client\http-request-2.txt POST /xfer/xfer HTTP/1.0 Host: y00122496:8080 User-Agent: Fossil/1.19-[fca3073621] Content-Type: application/x-fossil-debug Content-Length: 731 login y00122496 0a537607fd0379d45187960a4c16fc7d46ac8377 71c95440c46896e0cd9abe44dbf9498eae06369c pull 1b9fc5d540f690029289a6de049cc10ccf00e76f b47f5b8291724ebbe9ca27bdf555367d5a308f1d push 1b9fc5d540f690029289a6de049cc10ccf00e76f b47f5b8291724ebbe9ca27bdf555367d5a308f1d igot e0ed8945f6d2b387342051f102bb945eb8548828 igot 2059fac527a7d0c8b959afeb29e78d47cf57412a gimme ac1098901ce48c9b1f06dc10fb31509153c42b02 gimme 11060e36f3c43939f1b1cfb673ea589b1b2d3ddb igot a8407eb60d9c72630b93224f31bfc36a0f9d70de igot acc8828b67a8289bec332ae9216b040b47303acc igot 19d53dd50593b47cf6502018ac4f57a8407ddeec igot e0ed8945f6d2b387342051f102bb945eb8548828 igot 2059fac527a7d0c8b959afeb29e78d47cf57412a # AA004CFD947F923B7D9CDA9915DD8EB8CA2D9BE6 D:\client\http-reply-2.txt
Re: [fossil-users] Maybe a bug in sync
2011/8/16 Yujianbin yujian...@huawei.com vv repo delete ops.server vv init ops.server vv whoami --create Server i'm not sure what you're trying to show us - vv is not fossil. Fossil has no whoami command. vv serve --port 443 --public nor does it have a serve command. D:\clientvv history revision: 4:f34dca635cd1ddaae759488858ee316a0d849b9a Nor does fossil have a history command. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
Hi Stephan, That is another DVCS - Veracity(http://veracity-scm.com). Veracity has almost the same functions as Fossil. But it has not the defect of the function 'sync'. The scripts are under Veracity. Veracity has the executable file named 'vv.exe'. Best regards. Justin Yu Re: [fossil-users] Maybe a bug in sync Stephan Beal [sgb...@googlemail.com] 2011-08-16 (星期二) 21:41 2011/8/16 Yujianbin yujian...@huawei.com vv repo delete ops.server vv init ops.server vv whoami --create Server i'm not sure what you're trying to show us - vv is not fossil. Fossil has no whoami command. vv serve --port 443 --public nor does it have a serve command. D:\clientvv history revision: 4:f34dca635cd1ddaae759488858ee316a0d849b9a Nor does fossil have a history command. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
Hi Stephan, That is another DVCS - Veracity(http://veracity-scm.com). Veracity has almost the same functions as Fossil. But it has not the defect of the function 'sync'. The scripts are under Veracity. Veracity has the executable file named 'vv.exe'. Best regards. Justin Yu Re: [fossil-users] Maybe a bug in sync Stephan Beal [sgb...@googlemail.com] 2011-08-16 (星期二) 21:41 2011/8/16 Yujianbin yujian...@huawei.com vv repo delete ops.server vv init ops.server vv whoami --create Server i'm not sure what you're trying to show us - vv is not fossil. Fossil has no whoami command. vv serve --port 443 --public nor does it have a serve command. D:\clientvv history revision: 4:f34dca635cd1ddaae759488858ee316a0d849b9a Nor does fossil have a history command. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
Hi Justin, My English is not well. I don't know that you said everything worked means you get a different result of the last timeline command. My result is: Yes, I get a different result than you. What I find is for the server repository : === 2011-08-11 === 13:41:50 [925ffeb995] *CURRENT* client1 (user: tkott tags: trunk) 13:39:50 [0ba8f3b0aa] server0 (user: tkott tags: trunk) 13:39:24 [1b99421da6] initial empty check-in (user: tkott tags: trunk) I.e., fossil syncs, pushes, and pulls correctly. One thought just came to mind, you can add the option --httptrace to the fossil sync command. I don't actually know what it does, but it has been suggested before in other situations where something bout the sync isn't working. I believe it will create a couple of files in your repo folder that have a copy of the HTTP commands sent back and forth as described here: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04867.html. Give that a shot and let us know what happens. Tomek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
Indeed, I use my Windows PC as server and client. My %COMPUTERNAME% is Y00122496. My %USERNAME% is y00122496. Y00122496 haven't been defined as 127.0.0.1 in hosts. Y00122496 is the localhost and needn't to be defined. The server repo is in D:\server. The client repo is in D:\client. I guess they can run independently. And I use CMD.exe as my shell to run the scripts, not BY HAND. http://www.fossil-scm.org/download.html hasn't offer fossil V1.19. The foot of page http://www.fossil-scm.org/schimpf-book/index shows: Fossil version 1.19 [abe7b8335f] 2011-08-02 18:42:14 So I download the Zip archive from http://www.fossil-scm.org/index.html/info/abe7b8335f But I encounter fail on build it via VC++ 6.0: I'm in doubt whether the version of VC++ is correct. I can't find this info in http://fossil-scm.org/index.html/doc/trunk/www/build.wiki: I encounter fail on build it via VC++ 6.0: There is a trivial defect: two c:\msc\extra\include of '-I' cl -c -nologo -MT -O2 -I. -I..\src -I..\win\include -Ic:\msc\extra\include -Ic:\msc\extra\ include /Fo.\blob.obj -c blob_.c blob_.cblob_.c(22) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Follow the instruction on http://www.sqlite.org/debug1/wiki?name=compillingOnWindows I should download some software packages. I need more time to do it. Best regards. Justin Yu Re: [fossil-users] Maybe a bug in sync Tomek Kott [tkott.s...@gmail.com] 2011-08-10 (星期三) 22:42 Without using the batch files, I've done everything you have by hand using fossil 1.19 2011 07 22. When I go back to the server, and write fossil open ops, I correctly get the client1.txt file on the server side. Therefore, it is either a windows XP vs. 7 issue, or a fossil vs. 1.18 vs 1.19 issue. Please update to 1.19 and try the same script. One other possibility is that there is something related to the shell you are using. Are you running this on powershell or the cmd.exe? Two other confusing pieces to note: D:\clientfossil commit --comment client1 You can see: The first ‘Autosync’ will poll repo from server. Autosync: http://y00122496@y00122496:8080 Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Received: 170 4 0 0 Total network traffic: 321 bytes sent, 345 bytes received New_Version: 11de786c5c9d689c798399f2c37d98f5b5602c89 You can see: The second ‘Autosync’ will push repo to server. Autosync: http://y00122496@y00122496:8080 Bytes Cards Artifacts Deltas Sent: 539 9 0 0 Received: 264 6 0 0 Total network traffic: 459 bytes sent, 397 bytes received First, you can notice that on the push, no artifacts are sent. On my tests, there are two artifacts sent (I imagine it is the manifest and the file). Therefore, it is not surprising that the server never shows the client file. Second, I assume that you have y00122496 defined as 127.0.0.1 in your hosts file somewhere, since you can successfully clone from it. Same question as last time though: have you tried these same commands BY HAND to ensure that the batch file itself isn't the problem? Tomek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
Justin, Sorry, I completely forgot that I'm actually using the fossil version included from the SharpFossil project. You can download the version I'm using here: http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil/wiki?name=Downloads. However, I went and downloaded the version you are using, and tried the same commands, including using %COMPUTERNAME% and %USERNAME% as the parameters. Everything works for me as would be expected. Really the point at which it is failing seems to be the autosync portion, since it is not pushing and artifacts over, which indicates that the client1.txt is not being sent over. I tried this on a computer at work that has XP Pro SP3 installed, and everything worked. So, I would still recommend running all the same commands by hand with the version you can run. That way we can remove the batch file itself as the culprit. I would imagine that this is a firewall issue of some sort with XP. I don't know what might be the problem, but it doesn't seem to be a problem with fossil as far as I can tell. It works fine on my Win 7 and XP machines as expected. Tomek 2011/8/11 Yujianbin yujian...@huawei.com Indeed, I use my Windows PC as server and client. My %COMPUTERNAME% is Y00122496. My %USERNAME% is y00122496. Y00122496 haven't been defined as 127.0.0.1 in hosts. Y00122496 is the localhost and needn't to be defined. The server repo is in D:\server. The client repo is in D:\client. I guess they can run independently. And I use CMD.exe as my shell to run the scripts, not BY HAND. http://www.fossil-scm.org/download.html hasn't offer fossil V1.19. The foot of page http://www.fossil-scm.org/schimpf-book/index shows: Fossil version 1.19 [abe7b8335f] 2011-08-02 18:42:14 So I download the Zip archive from http://www.fossil-scm.org/index.html/info/abe7b8335f But I encounter fail on build it via VC++ 6.0: I'm in doubt whether the version of VC++ is correct. I can't find this info in http://fossil-scm.org/index.html/doc/trunk/www/build.wiki: I encounter fail on build it via VC++ 6.0: There is a trivial defect: two c:\msc\extra\include of '-I' cl -c -nologo -MT -O2 -I. -I..\src -I..\win\include -Ic:\msc\extra\include -Ic:\msc\extra\ include /Fo.\blob.obj -c blob_.c blob_.cblob_.c(22) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. Follow the instruction on http://www.sqlite.org/debug1/wiki?name=compillingOnWindows I should download some software packages. I need more time to do it. Best regards. Justin Yu Re: [fossil-users] Maybe a bug in sync Tomek Kott [tkott.s...@gmail.com] 2011-08-10 (星期三) 22:42 Without using the batch files, I've done everything you have by hand using fossil 1.19 2011 07 22. When I go back to the server, and write fossil open ops, I correctly get the client1.txt file on the server side. Therefore, it is either a windows XP vs. 7 issue, or a fossil vs. 1.18 vs 1.19 issue. Please update to 1.19 and try the same script. One other possibility is that there is something related to the shell you are using. Are you running this on powershell or the cmd.exe? Two other confusing pieces to note: D:\clientfossil commit --comment client1 You can see: The first ‘Autosync’ will poll repo from server. Autosync: http://y00122496@y00122496:8080 Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Received: 170 4 0 0 Total network traffic: 321 bytes sent, 345 bytes received New_Version: 11de786c5c9d689c798399f2c37d98f5b5602c89 You can see: The second ‘Autosync’ will push repo to server. Autosync: http://y00122496@y00122496:8080 Bytes Cards Artifacts Deltas Sent: 539 9 0 0 Received: 264 6 0 0 Total network traffic: 459 bytes sent, 397 bytes received First, you can notice that on the push, no artifacts are sent. On my tests, there are two artifacts sent (I imagine it is the manifest and the file). Therefore, it is not surprising that the server never shows the client file. Second, I assume that you have y00122496 defined as 127.0.0.1 in your hosts file somewhere, since you can successfully clone from it. Same question as last time though: have you tried these same commands BY HAND to ensure that the batch file itself isn't the problem? Tomek
Re: [fossil-users] Maybe a bug in sync
Without using the batch files, I've done everything you have by hand using fossil 1.19 2011 07 22. When I go back to the server, and write fossil open ops, I correctly get the client1.txt file on the server side. Therefore, it is either a windows XP vs. 7 issue, or a fossil vs. 1.18 vs 1.19 issue. Please update to 1.19 and try the same script. One other possibility is that there is something related to the shell you are using. Are you running this on powershell or the cmd.exe? Two other confusing pieces to note: D:\clientfossil commit --comment client1 You can see: The first ‘Autosync’ will poll repo from server. Autosync: http://y00122496@y00122496:8080 Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Received: 170 4 0 0 Total network traffic: 321 bytes sent, 345 bytes received New_Version: 11de786c5c9d689c798399f2c37d98f5b5602c89 You can see: The second ‘Autosync’ will push repo to server. Autosync: http://y00122496@y00122496:8080 Bytes Cards Artifacts Deltas Sent: 539 9 0 0 Received: 264 6 0 0 Total network traffic: 459 bytes sent, 397 bytes received First, you can notice that on the push, no artifacts are sent. On my tests, there are two artifacts sent (I imagine it is the manifest and the file). Therefore, it is not surprising that the server never shows the client file. Second, I assume that you have y00122496 defined as 127.0.0.1 in your hosts file somewhere, since you can successfully clone from it. Same question as last time though: have you tried these same commands BY HAND to ensure that the batch file itself isn't the problem? Tomek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
2011/8/3 Yujianbin yujian...@huawei.com D:\o is server, D:\m is client. ... D:\mcd /d D:\o ** ** D:\ofossil ls ** ** test.txt is NOT in the repository of server stephan@tiny:~$ f help ls Usage: f ls [-l] Show the names of all files in the current checkout. The -l provides extra information about each file. as far as i can see you haven't done an update on the server after committing test.txt. You commit and sync, but the server's checkout is still in its earlier state. On the server side you need to do: fossil up -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Maybe a bug in sync
2011/8/3 Yujianbin yujian...@huawei.com D:\o is server, D:\m is client. ** ** The content of tst_server.bat is: md D:\o cd /d D:\o if exist ops del /q ops if exist _FOSSIL_ del /q _FOSSIL_ fossil version @echo Please record the password and set it into tst_client.bat fossil new ops fossil open ops fossil server On the server, you don't need to do a fossil open. The repository, in this case, is ops. When you did the commit on the client side, the file you added was put in ops. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
