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] New features for merging
On Sun, 14 Aug 2011 19:16:50 -0700 Mike Meyer m...@mired.org wrote: [...] If you insist on them being files, then there's not much point in further discussion. And having them in files means you can bring the full power of unix to bear on them (which, of course, is why I want them *out* of my workspace - as they are just noise when working with *my* files), which is hard to argue with. But - any chance of moving them into the wiki? The fossil wiki command would let you work with them with almost the same power at the command line (i.e. - fossil extras | fossil wiki import settings/ignore_glob should work), and in return you get to edit the settings via the wiki gui. This is a rather beautiful idea but I always thought that wiki in fossil is not really versioned and it is also repository-wide (hence you woun't be able to have different ignore settings on different branches). Please correct me if I'm wrong. But if I'm not, the idea of using wiki for this kind of job won't work. ___ 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] New features for merging
On Mon, Aug 15, 2011 at 10:49 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Sun, 14 Aug 2011 19:16:50 -0700 Mike Meyer m...@mired.org wrote: [...] If you insist on them being files, then there's not much point in further discussion. And having them in files means you can bring the full power of unix to bear on them (which, of course, is why I want them *out* of my workspace - as they are just noise when working with *my* files), which is hard to argue with. But - any chance of moving them into the wiki? The fossil wiki command would let you work with them with almost the same power at the command line (i.e. - fossil extras | fossil wiki import settings/ignore_glob should work), and in return you get to edit the settings via the wiki gui. This is a rather beautiful idea but I always thought that wiki in fossil is not really versioned and it is also repository-wide (hence you woun't be able to have different ignore settings on different branches). Please correct me if I'm wrong. But if I'm not, the idea of using wiki for this kind of job won't work. Half right. Wiki pages are versioned, and you can use the UI to go looking through the older versions, etc. The version of fossil I have here (downloaded windows binary) doesn't have the ability to deal with wiki pages by version from the command line, thought it's listed as a TODO. Their doesn't appear to be any way to branch them, though. So yes, like the current version settings, you couldn't have different settings for different branches. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] new winsrv command: which port does it use?
I have compiled the latest trunk-version with the new winsrv command to test it. It leaves me slightly confused to which port Fossil uses this way. First I do a 'fossil ui' on an open checkout. This claims port 8080 (note: it could also be any other program already using port 8080) Next I do a 'fossil winsrv create' and a 'fossil winsrv start' inside *another* open checkout. This works fine: Service 'Fossil-DSCM' started. but no indication about which port is being used. http://127.0.0.1:8080 still brings me to the first server started with 'fossil ui' Only/If I stop that server, http://127.0.0.1:8080 http://127.0.0.1:8080/ is suddenly served by the 'Fossil-DSCM' Service (another repository)! Very confusing. Maybe I do not understand Windows services very well but should the 'fossil server show' command not at the very least show the port it is serving? ___ 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] New features for merging
2011/8/15 Lluís Batlle i Rossell virik...@gmail.com On Mon, Aug 15, 2011 at 02:41:48AM +, altufa...@mail.com wrote: Me too like fossil because of simplicity of one file / less file clutter. Why can't versionable settings be treated like a wiki or ticket page and versioned inside the repository itself rather than as a file in work area? Then we can also see changes done to [versioned] settings right there in timeline! Thinking of reasons... 1) You may not want versioned settings, and keep with one file. 2) The map to files is quite easy to use. Some people use, then, '.wiki' files in the repository instead of the usual wiki pages. 3) The file interface offers most version capabilities currently, in fossil. Easier to reach old version, allowing branching, branches of code may need different settings (ignore glob?). I have had this need many times. For example a build directory that must be ignored is moved. If I branch from the previous state and the ignores reflect the new state I now have irrelevant junk cluttering up my fossil status. Hardly the end of the world but really a completely unnecessary annoyance. I am very much looking forward to this mechanism being a part of the official build. 4) The versioned settings in files are *implemented* now. Having them ready in trunk should not annoy anyone who does not want to use them (if they control the repositories). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
