[fossil-users] Workaround for 'Uppercase/lowercase issue on Windows '
Found another workaround for the 'Uppercase/lowercase issue on Windows' reportet in ticket https://www.fossil-scm.org/fossil/tktview?name=d6d16fe1aa resp. discussed on the mailing list http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg18217.html. Since anonymous isn't allowed to edit tickets (anymore?) I'll post it here ;) To avoid the messed up file names don't `rename A a` directly but rather use an intermediate dummy directory: mkdir dummy fossil rename A dummy fossil rename dummy a rmdir dummy - updated .cmd from the above mentioned ticket - @echo off rem The following script was provided by Ross Berteig. Thanks! rem modified by Tontyna to provide a workaround rem Run this in an empty folder where it is safe to create and use a rem fossil repository. fossil new abc.fossil fossil open abc.fossil mkdir A cd A echo a a.txt echo c c.txt echo e e.txt echo g g.txt echo i i.txt fossil add * fossil ci --no-warnings -m Uppercase A --tag UPPERCASE cd .. rem Rename A to a via an intermediate name since batch files rem apparently can't do that in one step. move A b move b a rem Attempt to simply tell fossil about the name change. This fails. rem oved by Tontyna: fossil rename A a rem +++ the workaround +++ rem rename via an intermediate dummy-directory works rem the directory must exist otherwise fossil rename does nothing mkdir dummy fossil rename A dummy fossil rename dummy a rmdir dummy rem +++ the workaround +++ cd a echo b b.txt echo d d.txt echo f f.txt echo h h.txt echo i i.txt fossil add * fossil ci --no-warnings -m Lowercase A --tag lowercase cd .. rem echo Note that both A and a are present echo Note that only a is present. No mess anymore. fossil ls echo Now look at the Timeline and Files pages fossil ui pause --- EOF - Robert Engelhardt's workaround was (temporarily) enabling case sensitivity. And the question arose whether case insensitivity on Windows was only a 'cosmetic' setting. So I turned on case-sensitivity and played around with variations on uppercas/lowercase file names producing perplexing effects. Will have to do some more studies to decide whether the confusion is a real one or only exists in my brain (damaged by Windows). - Tontyna P.S.: What is the preferred habit on fossil-users? 'Re:' to older mails or start a new thread? Sorry if I did the wrong thing. There really shoud be a Mailing List Use - Recommended Practice document somewhere. ___ 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] {fossil-users] symbolic name tags
Oh, I see. The sym-prefixed special tags are automagically managed by Fossil. Being unacquainted to the internals of Fossil the wiki page confused me. Thought I'd have to add these sym-tags myself. Thanx to Andy (Bradford and Goth) for the clarification. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] {fossil-users] symbolic name tags
Reading /www/branching.wiki I stumbled upon the paragraph explainig symbolic name tags starting with *sym-* being special. Adding tag names with and without sym-prefix to a repo I couldn't see any functional difference. Did I miss something? Regards -Tontyna ___ 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] same port in use by concurrent fossil instances
Am 19.03.2015 um 19:36 schrieb Andy Bradford: Thus said Tontyna on Thu, 19 Mar 2015 11:58:40 +0100: Starting several fossil servers with ui increments port from 8080 onwards. Starting several fossil servers with server increments port ditto. Mixing ui and server instances results in double-bound ports. Don't know whether that's a Windows-only issue. This is not a Windows-only behavior. The server does not use any specific IP and in fact uses any (0.0.0.0) as shown in your netstat output. Whereas ui wants to be on 127.0.0.1 to restrict access to the local machine only. 127.0.0.1 is more specific, so your OS allows it (OpenBSD allows it to). There is no double-binding going on here. If you had 10 IP addresses you could have 10 things all listening on port 8080. If you point your browser to 127.0.0.1:8080 you'll get the UI instance. If you point your browser to 192.168.1.10:8080 (or whatever your IP happens to be) I imagine you'll get the server. Andy -- TAI64 timestamp: 4000550b1748 Thank you very much for your explanation. From now on I'll use http://localhost; to display repos served by `fossil ui` and http://computername; to request from `fossil server`. To avoid confusion in the browser (refresh a page with an URL/port that in the meanwhile points to another repo) I could apply clear-cut distinct stylings to my repos. - Tontyna P.S.: The mixed-up communication (aka double-bind) at work involved a server computer having multiple IPs. Will definitely recheck that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] same port in use by concurrent fossil instances
Starting several fossil servers with ui increments port from 8080 onwards. Starting several fossil servers with server increments port ditto. Mixing ui and server instances results in double-bound ports. Don't know whether that's a Windows-only issue. Example: When running `fossil server REPO_A` and `fossil ui REPO_B` at the same time both HTTP server instances will listen on port 8080. Experts will tell you that this is impossible and against builtin socket behaviour, bind() or listen() would never ever allow it, but that's what happens: C:\Oblong\fossiltestnetstat -ano | find :8080 TCP0.0.0.0:8080 0.0.0.0:0ABHÖREN 6516 TCP127.0.0.1:8080 0.0.0.0:0ABHÖREN 7312 PID 6516 and PID 7312 listening on 8080. Consequence is that REPO_A isn't accessible via HTTP. All http://localhost:8080/* requests go to the REPO_B server. When you close the REPO_B instance REPO_A magically reappears. I formerly underwent that double-bind-port feature in non-fossil context where -- depending on circumstances only heaven knows -- sometimes the first an sometimes the second server instance responded to requests on the port involved. Our TCP clients experienced funny mixed-up conversations. Seems that double-bind only happens for executables having the same base name (e.g. myTCPserver.exe or fossil.exe, different full paths don't matter). To prevent the double-bind we finally implemented a function PortInUse() which parses the output of `netstat`. Only workaround so far: Avoid ui and server at the same time and/or apply a --port below 8080 to your `fossil server`. - Tontyna ___ 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] Xekri skin: weird dropdowns on timeline page in Opera
Yes, '-o-display: block' fixes the issue. But only when there is no 'display:flex'. What's the 'hide-from-opera' css hack? - Tontyna Am 17.03.2015 um 02:04 schrieb Andrew Moore: Hello Tontyna! Thank you for the information about the problem you ran into with the Xekri skin. I don't have access to Opera, so I can not test any fixes to make sure it would work equally on Chrome and Firefox. A possible fix which uses -o-display: block for the div.submenu has been pushed to the skin-xekri branch. Please let me know if it works for you and I am open to any suggestions for a better solution. Andrew On Mon, Mar 16, 2015 at 5:54 PM, Tontyna tont...@ultrareal.de mailto:tont...@ultrareal.de wrote: Opera (12.17/Win32) produces gigantic selects -- see attached screenshot. Culprit is the display: flex property of div.submenu - Tontyna ___ fossil-users mailing list fossil-users@lists.fossil-scm.org mailto: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 ___ 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] Xekri skin: weird dropdowns on timeline page in Opera
Opera is not my favourite browser. The outdated instance is a relic. I run into the funny dropdowns when I (to no avail) tried to reproduce Albert's issue with fossil ui not working with recent chrome browser resp. Richies Missing timeline graph above 36 timeline items with all the browsers that happen to be on my computer. Cf. current thread on Browser support ;) - Tontyna Am 17.03.2015 um 04:59 schrieb Vikrant Chaudhary: The current version of Opera is 28, you should probably update your Browser. You are using a 2 year old version which comes with Presto engine (development of which is now discontinued by Opera), while newer versions use Blink engine. Cheers. - Vikrant On 17 March 2015 at 04:24, Tontyna tont...@ultrareal.de wrote: Opera (12.17/Win32) produces gigantic selects -- see attached screenshot. Culprit is the display: flex property of div.submenu - Tontyna ___ 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 ___ 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] fossil ui not working with recent chrome browser
Am 17.03.2015 um 21:08 schrieb jungle Boogie: Hello, On 17 March 2015 at 03:07, a...@gmx-topmail.de a...@gmx-topmail.de wrote: -Can you use a different Windows computer? I did, and there I don't have the problem (I'm sick and write this from home, I probably will do more tests with other computers/browsers in the next days once I'm back to work...) Create a new Windows profile on the computer you do have available and see if the problem occurs with a brand now fossil repo. Get well soon! New user sounds like a good idea! I'm 100% shure it's not the repo. It must be something else on the computer. One more idea: How many fossil.exe do you see in the TaskManager when the corruption occurs? I know it sounds silly, but in the last months I had strange adventures with Windows services and same port in use by more than one application... - Tontyna ___ 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] fossil ui not working with recent chrome browser
Am 17.03.2015 um 21:01 schrieb a...@gmx-topmail.de: Is there something special Albert's system performs in its TMP folder? nothing that I know of. And it would have to be something that changed very recently, before about a week or so I didn't see these problems... My last Windows 7 update happened to be 5 days ago. And the next one is waiting for me to shutdown the computer. I'm not in the support team but I heard that last week some of our customers did have problems right after Win7 update. Will ask my colleagues for details. If that happened on my computer I'd recompile Fossil, commenting out the line #165 in winhttp.c : -- file_delete(zReplyFName); and have a look at the `fossil_server_P*_out*.txt` files. that's a good point. As I don't usually compile myself it might take a little before I can report what the outcome is... Did it right now. If you want I can e-mail the tweaked fossil.exe to you. You won't be really happy with the contents of the replyfiles. Fossil produces 'Content-Encoding: gzip'. But at least you can watch what files are produced when Firefox resp. Chrome requests the same page and compare their 'Content-Length'. Investigating the Windows Event Log might be another option. I tried to find anything interesting there, but was not successful. But the windows event log is not exactly something I understand very well, any pointers to what I should pay attention to are welcomed... Me too. I never find nothing there. Was just a stupid idea ;) - Tontyna, run out of ideas now and not alone with that :-), thanks for your efforts anyway... Albert Three cheers to jungle Boogie! He had yet another idea! ___ 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] fossil ui not working with recent chrome browser
Am 16.03.2015 um 11:24 schrieb a...@gmx-topmail.de: I have now also made some additional tests: 1) local instance of a simple python webserver instance - complete pages for all browsers 2) remote instance of apache+trac - complete pages for all browsers 3) remote instance of apache+trac through ssh-tunnel - complete pages for all browsers 4) remote public fossil instances - complete pages for all browsers 5) local fossil instances (standalone server) on Win7 - incomplete pages for all browsers except firefox, which shows complete pages 6) my own remote fossil standalone instances on Linux server - incomplete pages for all browsers except firefox, which shows complete pages 7) my own remote fossil standalone instances on Linux server via ssh-tunnel - incomplete pages for all browsers except firefox, which shows complete pages 8) foreign remote fossil instances- complete pages with all browsers The above experiments indicate that CGI Fossil works and standalone server fails. So what's the difference between running standalone and CGI? Looking at the Fossil source code I see that in either case the response is produced by redirecting the output of fossil_system() into a temporary file, then send() the contents of that file back, and finally deleting the file. I'm not an expert in programming http servers and the likes. Only thinkering. Assuming send() isn't asynchronous and the fossil server is still running after an incomplete page I naively can imagine the following reasons for truncated html: 1. fossil_system() produces different output = Can't be because in Firefox the pages are complete 2. Sending the contents of the temporay file stops midways when standalone and not requested by Firefox. = Sounds like nonsense. The send()-loop sends until EOF. 3. The temporary file is truncated (or deleted) while Fossil is in the send-loop. = Hu?! 4. Fossil sends the complete response but Browser ignores the half of it. = Why should he? Are Chrome, IE, Opera more impatient than Firefox is? Is CGI delivery faster than standalone? Q: Does send() expect the receiver to commit? As I said: I'm not an expert. 5. Other forces that might interrupt a HTTPResponse? = ??? There is one difference between CGI and standalone I spotted: When I run Fossil standalone the output file is located in %LOCALAPPDATA%\Temp. When I run Fossil as CGI (Xampp) the temporary path is C:\xampp\tmp Is there something special Albert's system performs in its TMP folder? If that happened on my computer I'd recompile Fossil, commenting out the line #165 in winhttp.c : -- file_delete(zReplyFName); and have a look at the `fossil_server_P*_out*.txt` files. Investigating the Windows Event Log might be another option. - Tontyna, run out of ideas now ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Xekri skin: weird dropdowns on timeline page in Opera
Opera (12.17/Win32) produces gigantic selects -- see attached screenshot. Culprit is the display: flex property of div.submenu - Tontyna ___ 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] Missing timeline graph above 36 timeline items (?!)
The weirdest thing is that I have reverted to old versions and I'm still unable to see the full graph! First idea: cached stylesheet? Although that wouldn't explain why you can see 36 items on the Fossil site but not on localhost. Can't imagine that the HTML served by fossil.exe is sooo different from the HTML produced on fossil-scm.org -- what's the skin of your repo? JavaScript issue? Only the arrows and boxes of the timeline are missing? The Footer is present? When you hover the empty timeline space: does the mouse pointer change? Does clicking on two different positions bring you to the Check-in-Differences page? ___ 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] Fossil version 1.32
Am 15.03.2015 um 09:46 schrieb Baruch Burstein: Can we still have the changelog of the older versions on the download page, even without the links? And/or a link to older versions like on http://www.sqlite.org/releaselog/3_8_8_3.html ___ 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] fossil ui not working with recent chrome browser
Probably nothing to do with Fossil but that's an interesting 'feature', reminds me somehow of features I had some times ago with SWF rendering. Maybe I get an idea when I see the page source Opera or Chrome claim to have received when they display only half of the new ticket page... Additional question: What's the URL in the addressbar? Tontyna Am 15.03.2015 um 18:43 schrieb a...@gmx-topmail.de: So my problems are most likely a false alarm concerning fossil despite the fact that my local fossil repos are the only cases where the browsers show that problem. I'll probably test whether other webservers on my local machine have the same problem and if that would be the case confirm that this is nothing fossil specific. But of course if anyone has an idea about which parts of Windows could cause such a problem I'd be all ears... Albert ___ 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 skin: Blitz
Am 14.03.2015 um 16:52 schrieb jungle Boogie: Does anyone else have issues reading diffs? Me too. After years spent glaring at computer screens Ctrl++ became my friend -- being too obstinate to wear glasses I'm probably not a yardstick for proper font-size. ___ 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] fossil ui not working with recent chrome browser
Am 15.03.2015 um 00:30 schrieb a...@gmx-topmail.de: yes, I just did that (Fossil version [6c40678e91] 2015-03-14 13:20:34) and still see the same problem: only part of the html-code is rendered and when I look at the page source that chrome claims to have received that is also incomplete. I have now made some more experiments and found that I have the same problems with internet explorer and opera as well, but with firefox I don't have it. As I saw this right after a chrome update I was mislead to believe it was because of that, but probably it is something completely unrelated to that. Of course that makes me wondering even more whether anyone else has ever seen such behavior... Can't reproduce your new ticket page problem using Fossil 1.32 on Win 7 (64bit). Tested with Default, Xerki and San Francisco skin. Opera 12.17 and IE 11 render fine. Which skin are you using? Did you edit the CSS or the header? ___ 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] How to fix parallel timeline
Am 13.03.2015 um 10:59 schrieb Jan Nijtmans: If the initial commit contains files, Fossil 1.27 doesn't see that, and nothing reveals they are really there. Therefore, those files look as they have been lost, but they really aren't: just upgrade to Fossil 1.28 or later and the files will magically be back again. Thats right. Switching to a newer Fossil the timeline still is split but all files (from both lines) are accessible in the reposiory. Nonetheless: I'm lost on how to join the lines again -- no chance without a common ancestor. Seems to be a repository containing two separate repositories. A tricky SQL statement could probably create the required records... Thanks to Tontyna for his excellent analysis, which made it (at least to me) fully clear what really happend here. My pleasure. BTW it's her not his ;) Regards, Tontyna ___ 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] How to fix parallel timeline
Am 11.03.2015 um 18:48 schrieb David Mason: The problem was that the version of fossil that apt-get used was version 1.27 (I think... maybe 1.29) and I created the fossils with 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them). This is the resource page I point them at: Can't imagine how your students were able to work with 1.27 on a repository created with 1.30 without doing a fossil rebuild With 1.29 I'm not even able to open the 1.30 repo. With 1.27 I can open the cloned repo but cannot add files. Managed to reproduce your corrupted timeline: 1. Created a repo with Fossil 1.30 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all 4. created a new file 5. `fossil add` warned me about the wrong schema version 6. did what I was told: `fossil rebuild` 7. Now `add .` worked fine 8. `commit` warned me about autosync not working I ignored that an continued. 9. fossil ui/timeline -- see attached picture ___ 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] How to fix parallel timeline
Am 12.03.2015 um 18:25 schrieb Andy Bradford: Thus said Tontyna on Thu, 12 Mar 2015 11:40:32 +0100: 1. Created a repo with Fossil 1.30 forgot to mention: added a file and committed 2. Switched to Fossil 1.27 3. clone/open worked without warning BTW: open produced a _FOSSIL_ but the local reposirory was empty, i.e no checked-out files at all According to David's instructions[1], there were files added to the repository before it was made available for cloning to the students... Does this still happen if you add files prior to cloning? The repo I created with 1.30 contained one file but as I said: after open (seemingly successfully because I got no warnings) the local root was empty besides the _FOSSIL_ database. Don't know what `fossil rebuild` does with the repository (downgrading 1.30 to 1.27? How? What has `clone` done already?) but the parallel timeline definitely has something to do with the initial commit -- the clone contains 1 checkin, the above mentioned file (btw. Dave's 'default setup' files). Maybe when Fossil 1.27 sees the 1 it thinks: Oh, that's a repo containing nothing but the initial empty commit which we abandoned in version 1.30 but I don't know nuthin about 1.30. and gets tangled up. Because surprise! When I did the same with an EMPTY master repository or a master containing MORE THAN ONE commit -- no parallel timeline. Everything is working as expected. Except of course autosync fails when committing: Error: database schema is out-of-date on the server -- I'm wondering why your students who apparently read Fossil's output (and did a `rebuild` accordingly) didn't notify you of that. Or did you turn off autosync? Q: Is it worth investigating this issue? How could/should one make previous versions forward-compatible? Current and future versions could probably refuse to rebuild a repo with a newer schema... To reproduce Dave's timeline I was happy to still get Fossil 1.27 from the download page, but --- I think Fossil 1.30 should be removed from there or at least be tagged as don't use it with newer repos. - Tontyna ___ 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] Justification for two-step mv and rm
Am 09.03.2015 um 10:09 schrieb Jan Nijtmans: Done now: http://www.fossil-scm.org/index.html/info/8cf976d24689ae9e This means that whatever happens with fossil rm|mv|delete, the fossil rename and fossil forget will continue to function as they do now. Hurray and thank you! Will `addremove` become `addforget`? (Sorry, couldn't resist nitpicking.) ___ 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] Working with Windows mapped network drives
This has nothing to do with mapped drives. You'll get not found with any drive root -- C:\, D:\... Fossil cuts off the trailing backslash with the result that stat() resp lstat() returns an error = not found. I'm not shure whether and if yes in which function(s) -- file_canonical_name(), file_isdir(), file_wd_isdir(), file_simplify_name()... -- a 'when-on-windows-and-path-length-is-2-and-starts-with-A..Z-and-ends-with-colon-the-add-slash' correction should be implemented. Until your S:\-problem I didn't even think about putting a whole drive in one repository... -Tontyna Am 01.03.2015 um 10:57 schrieb Milo Rambaldi: Hi, I'm currently trying out fossil and ran into a problem using mapped network drives. In most tutorials I found on the net, the command used to add files to the repository is add . which doesn't work on a network drive: ---snip--- C:\net use s: \\sandbox\htdocs Der Befehl wurde erfolgreich ausgeführt. S:\fossil new d:\test.repo project-id: b0755e4c2a55d06275cc8158d4d10cbe386ff3a7 server-id: 0bedf33b9ddbdaa06d7157ef72c6d242f904979e admin-user: milo (initial password is **) S:\fossil open d:\test.repo project-name: unnamed repository: d:\test.repo local-root: S:/ config-db:C:/Users/milo/AppData/Local/_fossil project-code: b0755e4c2a55d06275cc8158d4d10cbe386ff3a7 checkins: 0 S:\fossil add . not found: S: S:\fossil add s:\ not found: S: S:\fossil add s:/ not found: S: ---snip--- Is there any way to do this? Thanks, m. ___ 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
[fossil-users] ls_cmd patch for consistency
'fossil status' and 'fossil changes' report missing files as MISSING,
while 'fossil ls -v' incorrectly calls them ADDED.
The following patch rearranges the order of file status checks in
ls_cmd() to make it behave like status_report()
Index: checkin.c
==
--- checkin.c
+++ checkin.c
@@ -349,20 +349,20 @@
int chnged = db_column_int(q,3);
int renamed = db_column_int(q,4);
char *zFullName = mprintf(%s%s, g.zLocalRoot, zPathname);
const char *type = ;
if( verboseFlag ){
- if( isNew ){
-type = ADDED ;
- }else if( isDeleted ){
+ if( isDeleted ){
type = DELETED;
}else if( !file_wd_isfile_or_link(zFullName) ){
if( file_access(zFullName, F_OK)==0 ){
type = NOT_A_FILE ;
}else{
type = MISSING;
}
+ }else if( isNew ){
+type = ADDED ;
}else if( chnged ){
if( chnged==2 ){
type = UPDATED_BY_MERGE ;
}else if( chnged==3 ){
type = ADDED_BY_MERGE ;
A month ago I managed to post a ticket about that subject:
https://www.fossil-scm.org/fossil/tktview?name=92fedcbc7d
Since then I learned that tickets are seldom reviewed...
Q: Is that the reason why there is no more new ticket for anonymous users?
-Tontyna
___
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] Justification for two-step mv and rm
Am 06.03.2015 um 15:46 schrieb j. van den hoff: On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna tont...@ultrareal.de wrote: I'd prefer that default `rm`/`mv` without options leave my file system alone. A `--forcefilesytem` flag would be a convenient enhancement. personally, I would _not_ like to see a mandatory `--forcefilesystem' option in order to get the usually desired behaviour. I totally agree, the --forcefilesystem was just a reminisence to the '-f' option proposed in previous mails. Too many options for any command are puzzling, always have to lookup what the command does depending on the applied flags. otherwise, see the previous mail by jan nijtmans which proposes a very sensible solution in my view: create a new alias `forget' for the current `rm' (which then should become the sole command performing that sort of operation (removing file from `fossil' tracking w/o touching file system) in due time -- thr sooner the better ...) and start to use the already existing `rename' instead of `mv'. this would ease the way of making rm/mv act like they really should (in the view of most people I really would say -- and that's an important criterion w.r.t. what a good default behavior should be) namely like what is happening in `hg' (I agree with warren young that the `hg' people seemingly have thought long enough about this and found a good solution and implemented enough options to cover all relevant use cases). On Windows neither `mv` nor `rm` does suggest anything to me other than what `fossil help` tells; but since the majority here associates touch the file system with those words it seems to be a good idea to let the commands exactly do that. I don't mind how the commands are named as long as they exist. Much cleaner to have different commands for different tasks. Even better when the command is self-explanatory. another point which has already been made in this thread, but might be emphasized: of course `mv' and `rm' already touch the file system quite regularly namely on the other end: someone updating from your repository (or your remote repo to which you (auto)sync)) after you performed `mv' or `rm' will of course modify his checkout (as indeed, it should). it makes (usually, but not always I admit) no sense that locally one has to go again and again through the routine of mirroring each and every `fossil rm' and `fossil mv' by a corresponding file system action. I understand that some people _want_ this but there needs would be satisfied if that is achieved by `rename/forget' in the future. Good to mention that point -- almost forgot that one of the reasons to introduce a CVS instad of only syncing directories is the question of how to get rid of unused garbage (there is always at least one developer creating 'old/', '.keep' an the likes an never deleting anything just in case) ___ 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] Justification for two-step mv and rm
I'm in the 1%, too. Perhaps that's because of my OS being Windows and me being a Fossil newbie. Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. I'd prefer that default `rm`/`mv` without options leave my file system alone. A `--forcefilesytem` flag would be a convenient enhancement. -Tontyna BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. Am 04.03.2015 um 18:24 schrieb paul: On 03/03/15 22:27, j. van den hoff wrote: . so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). I'm in the 1%. I prefer _not_ to use the command line. So if I want to move a file or directory I usually do that with a file browser. Same for deleting. When I eventually come to doing a check-in, renamed/deleted files show up in the missing tab of my fcommit GUI (*), and it's then, using the GUI, that I tell fossil what I've done, and then I commit. If fossil mv also moves files on a filesystem, I'd be happy with that, so long as I can still use a file browser as I'm doing now. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. Regards, Paul (*) www.p-code.org/fcommit ___ 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] Justification for two-step mv and rm
Am 06.03.2015 um 18:45 schrieb Ron W: On Fri, Mar 6, 2015 at 9:11 AM, Tontyna tont...@ultrareal.de mailto:tont...@ultrareal.de wrote: Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. I am curious which IDE you and your team are using. Also, why you chose to write a stand-alone GUI application for Fossil rather than configure your IDE to interact with Fossil. It's mainly Embarcadero Delphi and of course it's possible to write widgets or post-build-scripts to do basic stuff and for shure I'll do that. Root cause for the GUI is: To incline my boss towards Fossil we need something he will integrate without grumbling into his personal workflow. Some other reasons are - explore Fossil in a comfortable way - our products contain many files the IDE has no clue of - psycho-wise it serves the feeling of being in charge ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] tech_overview.wiki patch
The environment variable 'FOSSIL_HOME' introduced in 1.31 should be documented: Index: www/tech_overview.wiki == --- www/tech_overview.wiki +++ www/tech_overview.wiki @@ -131,8 +131,11 @@ database is named _fossil (using an underscore as the first character instead of a dot) and is located in the directory specified by the LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. +You can override this default location by defining the environment +variable FOSSIL_HOME pointing to an appropriate (writable) directory. + h32.2 Repository Databases/h3 The repository database is the file that is commonly referred to as the repository. This is because the repository database contains, ___ 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
Re: [fossil-users] tech_overview.wiki patch
Sorry, clicked wrong button in eMail client -- should have been a new thread not a reply... Tontyna ___ 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] build.wiki patch
And please: In the '2.0 Compiling/MinGW' paragraph a note about not using MinGW-4.0 cause it breaks e.g. the extras command: Index: www/build.wiki == --- www/build.wiki +++ www/build.wiki @@ -107,13 +107,16 @@ lipiUnix without running configure/i → if you prefer to avoid running configure, you can also use: bmake -f Makefile.classic/b. You may want to make minor edits to Makefile.classic to configure the build for your system. -lipiMinGW/MinGW-w64/i → Use the mingw makefile: +lipiMinGW3.x (not 4.0)/MinGW-w64/i → Use the mingw makefile: bmake -f win/Makefile.mingw/b. On a Windows box you will need either Cygwin or Msys as build environment. On Cygwin, Linux or Darwin you may want to make minor edits to win/Makefile.mingw to configure the cross-compile environment. +brbr +Hint: Don't use MinGW-4.0, it will compile but fossil won't work +correctly, see +a href=https://www.fossil-scm.org/index.html/tktview/18cff45a4e210430e24c;https://www.fossil-scm.org/index.html/tktview/18cff45a4e210430e24c/a. lipiMSVC/i → Use the MSVC makefile. First change to the win/ subdirectory (bcd win/b) then run bnmake /f Makefile.msc/b.brbrAlternatively, the batch Am 01.03.2015 um 22:45 schrieb jungle Boogie: Hello All, Some slight corrections to the build.wiki page: Index: www/build.wiki == --- www/build.wiki +++ www/build.wiki @@ -33,11 +33,11 @@ emreleased/em versions of fossil are available from the a href=http://www.fossil-scm.org/download.html;downloads page/a. To obtain a development version of fossil, follow these steps:/p ol -lipPoint your web browser at +lipPoint your web browser to a href=http://www.fossil-scm.org/; http://www.fossil-scm.org//a./p/li lipClick on the a href=http://www.fossil-scm.org/fossil/timeline;Timeline/a @@ -48,11 +48,11 @@ link./p/li lipFinally, click on one of the Zip Archive or Tarball links, according to your preference. These link will build a ZIP archive or a gzip-compressed tarball of the -complete source code and download it to your browser. +complete source code and download it to your computer. /ol h2Aside: Is it really safe to use an unreleased development version of the Fossil source code?/h2 @@ -66,11 +66,11 @@ repository change that prevent loss-of-work due to bugs. The Fossil [./selfhost.wiki | self-hosting repositories], especially the one at [http://www.fossil-scm.org/fossil], usually run a version of trunk that is less than a week or two old. Look at the bottom -right-hand corner of this screen (to the right of This page was +left-hand corner of this screen (to the right of This page was generated in...) to see exactly which version of Fossil is rendering this page. It is always safe to use whatever version of the Fossil code you find running on the main Fossil website. h22.0 Compiling/h2 ___ 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] Fossil 1.30 : db_record_repository_filename() never writes ckout to REPOSITORY.config
Wow! Already fixed -- Execute 'optional' SQL statements in their original order https://www.fossil-scm.org/fossil/info/24d7ebe12afa2f72 Thanks ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil 1.30 : db_record_repository_filename() never writes ckout to REPOSITORY.config
Since Fossil 1.30 the function db_record_repository_filename() in db.c
performs update of config table with two commands:
1. DELETE record to circumvent caseInsensitivity problems:
db_optional_sql(repository,
DELETE FROM config WHERE name %s = %Q;,
filename_collation(), zCkoutSetting
);
2. UPDATE record:
db_optional_sql(repository,
REPLACE INTO config(name,value,mtime)
VALUES(%Q,1,now());,
zCkoutSetting
);
Statements collected by db_optional_sql() are executed in
db_end_transaction() but in REVERSE ORDER. So the DELETE statement will
be the last and withdraws the UPDATE.
I applied the following patch to my fossil.exe, swapping the statements:
Index: db.c
==
--- db.c
+++ db.c
@@ -2138,19 +2138,19 @@
REPLACE INTO global_config(name, value)
VALUES(%Q,%Q);,
zCkoutSetting, blob_str(full)
);
db_swap_connections();
-db_optional_sql(repository,
-DELETE FROM config WHERE name %s = %Q;,
-filename_collation(), zCkoutSetting
-);
db_optional_sql(repository,
REPLACE INTO config(name,value,mtime)
VALUES(%Q,1,now());,
zCkoutSetting
);
+db_optional_sql(repository,
+DELETE FROM config WHERE name %s = %Q;,
+filename_collation(), zCkoutSetting
+);
fossil_free(zCkoutSetting);
blob_reset(localRoot);
}else{
db_swap_connections();
}
==
[Another option would be to execute the db.azBeforeCommit array in
db_end_transaction() in reversed order but maybe there was a reason
other than convenient programming style.]
Now that db_record_repository_filename() works for me I experience
something else -- opening a new repository still doesn't report the
'ckout' to REPOSITORY.config.
Cause: By default there is *no initial commit* in Fossil 1.30.
'open_cmd' calls 'checkout_cmd' which starts a transaction. But since
there are no leaves or events or blobs in a new repository `zVers` is 0
and the transaction isn't commited, discarding the optional sqls from
'db_record_repository_filename'.
Of course the first commit or `init --date-override` will do the trick.
BTW: What's the reason for storing the 'ckout' in the REPOFILE via
'db_optional_sql'? Why not via 'db_multi_exec'?
Tontyna
___
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
Re: [fossil-users] No extras files when built with mingw32-4.0-gcc-4.8.1
Switched to MinGW-w64 -- works like a charm. Thanks. See also: https://www.fossil-scm.org/index.html/tktview/18cff45a4e210430e24c Oh my! I saw that ticket but filed it under Windows XP -- who cares?. If I had a Fossil-Login with edit rights I'd put a warning about MinGW 4.0 in the Wiki https://www.fossil-scm.org/index.html/doc/trunk/www/build.wiki ___ 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
[fossil-users] No extras files when built with mingw32-4.0-gcc-4.8.1
When compiled with mingw32-4.0-gcc-4.8.1 (32-bit) the 'extras' command doesnt list any new files (Windows 7 64Bit, MSYS shell). Reason is: config.h (and sqlite3.h and tcl.h) defines _USE_32BIT_TIME_T which forces 'time_t' to be 32bit resulting in readdir() returning a dirent struct with dirent-d_name not pointing to the filename at all (displaced by 16 Bytes). Maybe the 32bit time_t is required for other parts of Fossil but vfile_scan() cant find anything. My current workaround is compiling against a modified dirent.h (with __time64_t instead of time_t) and until now it seems to have no ugly side effects. But that cant be the solution... Tontyna ___ 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
