[fossil-users] Re: debugging fossil with VisualStudio debugger

2016-11-04 Thread arnoldemu
Hi Artur,

Thank you for the information. I never knew an exe could be debugged this way 
because I've never needed to do it that way.

What I would like to point out is that for most visual studio and windows users 
this is a strange way to work.

Windows users are used to working almost exclusively through the gui and using 
devenv or msbuild is normally restricted to running in a batch file or on a 
build machines as some kind of build for end user or for a verification process.

For working with visual studio, I used to have to reboot my machine every day, 
but now I leave it on because it's much more stable. I find the visual studio 
icon (normally pinned to the taskbar), start up visual studio, find the 
solution, build the code, press f5 to launch the debugger, step through and 
debug it via the watch windows, local registers, callstack etc.

Debugging is easy because I can hover over a variable and it tells me it's 
value, or put it into the watch window. I can also go through structures easily 
by expanding and contracting the + mark next to the structure in the watch 
window.

It's just a different way of working compared to other OS's.

The solution file I posted was not the normal one visual studio uses. Normally 
a project type is defined and files are added and visual studio performs the 
build and link using that information. In this case I setup a project in 
makefile mode and configured it to make debug or release builds. 

I also included the original source since the other files are not there before 
a build is initiated. I was still able to place a breakpoint anywhere in the 
code, step through the code and view the variables and their values. For a 
normal visual studio user this is closer to what they know.




___
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] Synchronizing endless loop

2016-11-04 Thread Florian Balmer
Andy Bradford:

> This error would seem to indicate that your client sync code
> doesn't actually know what the uvigot card is

Indeed, if I get it right from following the code paths, there are
separate functions to handle synchronization for the client:

http://www.fossil-scm.org/index.html/artifact/0d5ab26abb?txt=1=1681-1689

and for the server:

http://www.fossil-scm.org/index.html/artifact/0d5ab26abb?txt=1=1127-1140

The client code is processing the "uvigot" card:

http://www.fossil-scm.org/index.html/artifact/0d5ab26abb?txt=1=2113-2183

The counterpart for the server handler is missing (that's where the
"server says: bad command" message comes from), but that's probably
intentional, as inferred from this comment:

http://www.fossil-scm.org/index.html/artifact/0d5ab26abb?txt=1=682-685

The `send_unversioned_file()' function should only generate "uvigot"
cards on the server (that is, for the client), but the function is
also called from the client sync code (generating "uvigot" cards for
the server), without discrimination of client or server mode.

I have rebuilt the Fossil client binary with an extra flag passed to
this function to indicate whether "uvigot" cards are desired or not.
The error message is gone, but unversioned files are not synchronized
at all, that way.

So I feel that the server should handle "uvigot" cards as well, and
indicate the unversioned files that the client should transfer.

Let's see if I dare diving any deeper ... ;-)

--Florian
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users