Re: [fossil-users] home directory must be writeable
On Mar 18, 2015, at 5:08 PM, Abilio Marques abili...@gmail.com wrote: HOME=. ./fossil command Here’s a thought: Someone on this list gave me the idea of aliasing “fossil” to “f”. I do it with a symlink instead of a shell alias so that it works even in places like a Vim :! command. If you were willing to develop such a habit, you could do it with a shell script instead, which could always set HOME to someplace writeable. ___ 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] home directory must be writeable
Actually they do allow (and sometimes encourage) you to connect over ssh, and they have bash with history... but the file is written inside a directory called $HOME/data (which is writeable). Openshift is a nice service. I've used it for some time now, no issues whatsoever, but (there is always a but)... sometimes they take the way people normally work in UNIX, put it in a blender, and serve that. Even regular applications like wordpress get completely modified beyond recognition (I'm talking about directory structure). I suppose it has something to do with the fact they sell the product as a PaaS, so it's easy to setup and run from the outside. Yet, under the hood, they've got the most complicated ways to make it work. $HOME pointing to a non writable directory goes with that philosophy. On Thu, Mar 19, 2015 at 5:58 PM, Stephan Beal sgb...@googlemail.com wrote: Presumably they don't expect users to use the shell, as the shell history is also (normally) saved in the home dir (except in some ultra-pedantic setups where the history is stored in a place where the user cannot access/edit it). - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Mar 19, 2015 11:24 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com wrote: But you're right, now that I think about it, is the only time I've ever seen a home directory not owned by the corresponding user but by root. Does the hosting service provide special commands for creating directories and files in your home directory? ___ 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] Is this a crazy idea?
[Default] On Thu, 19 Mar 2015 19:22:14 -0430, Abilio Marques abili...@gmail.com wrote: Having said these things, I must confess that in my mind, I find the staging area a difference that's not easily solved. Perhaps some of you have thought about this before, and have ideas on how to simulate it in a clean way. Any idea on my idea is welcomed. Isn't that solved by the ability of fosil to have multiple checkouts for the same repository, each in its own branch? I agree it might be hard to write a shim for that. -- Regards, Cordialement, Groet, Kees Nuyt ___ 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] home directory must be writeable
On 3/19/15, Abilio Marques abili...@gmail.com wrote: Actually they do allow (and sometimes encourage) you to connect over ssh, and they have bash with history... but the file is written inside a directory called $HOME/data (which is writeable). In your .bashrc script (wherever that is) can you just add a line that says: export FOSSIL_HOME=$HOME/data That will probably get it working better for you. Openshift is a nice service. I've used it for some time now, no issues whatsoever, but (there is always a but)... sometimes they take the way people normally work in UNIX, put it in a blender, and serve that. Even regular applications like wordpress get completely modified beyond recognition (I'm talking about directory structure). I suppose it has something to do with the fact they sell the product as a PaaS, so it's easy to setup and run from the outside. Yet, under the hood, they've got the most complicated ways to make it work. $HOME pointing to a non writable directory goes with that philosophy. On Thu, Mar 19, 2015 at 5:58 PM, Stephan Beal sgb...@googlemail.com wrote: Presumably they don't expect users to use the shell, as the shell history is also (normally) saved in the home dir (except in some ultra-pedantic setups where the history is stored in a place where the user cannot access/edit it). - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Mar 19, 2015 11:24 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com wrote: But you're right, now that I think about it, is the only time I've ever seen a home directory not owned by the corresponding user but by root. Does the hosting service provide special commands for creating directories and files in your home directory? ___ 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 -- D. Richard Hipp d...@sqlite.org ___ 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] home directory must be writeable
On 3/19/15, Abilio Marques abili...@gmail.com wrote: Yes indeed, and that's something new for me. It was documented just a few weeks ago. Thanks a lot! Looks cleaner that way. So someone was in my same situation, or is there another useful reason for having that var? I remembered that change as having occurred years and years ago. But upon consulting the timeline, I see that Joe put it in two months ago. I don't recall the exact reason. -- D. Richard Hipp d...@sqlite.org ___ 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 server for timeline will return empty result for some parameters max
I wasn't sure if my attachment made it through the mailing list. Is there an issue/report/task created for this which I can continue following instead of through the mailing list? I couldn't figure out how to create an issue on the fossil-scm site. On Mar 18, 2015, at 10:30 AM, die.drachen die.drac...@gmail.com wrote: I attached the output (using lldb instead of gdb). fossil-debug.txt On Mar 18, 2015, at 8:12 AM, Richard Hipp d...@sqlite.org wrote: On 3/18/15, die.drachen die.drac...@gmail.com wrote: Unfortunately I'm unable to distribute the repo, which is also quite large (~730mb .fossil file, 93k commits). Are there additional measures I can take to get diagnostic information? Compile your own Fossil from trunk sources, using options -O0 -g. Then run gdb fossil and within gdb type: run test-http REPOFILENAME (filling in the appropriate filename, of course). There will be no prompt, but Fossil is waiting for input at this point. Type: GET /timeline?n=421y=all with no leading spaces and the press Enter twice. When you hit the error, type bt and send me the output. -- D. Richard Hipp d...@sqlite.org ___ 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] home directory must be writeable
Yes indeed, and that's something new for me. It was documented just a few weeks ago. Thanks a lot! Looks cleaner that way. So someone was in my same situation, or is there another useful reason for having that var? On Thu, Mar 19, 2015 at 6:39 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Actually they do allow (and sometimes encourage) you to connect over ssh, and they have bash with history... but the file is written inside a directory called $HOME/data (which is writeable). In your .bashrc script (wherever that is) can you just add a line that says: export FOSSIL_HOME=$HOME/data That will probably get it working better for you. Openshift is a nice service. I've used it for some time now, no issues whatsoever, but (there is always a but)... sometimes they take the way people normally work in UNIX, put it in a blender, and serve that. Even regular applications like wordpress get completely modified beyond recognition (I'm talking about directory structure). I suppose it has something to do with the fact they sell the product as a PaaS, so it's easy to setup and run from the outside. Yet, under the hood, they've got the most complicated ways to make it work. $HOME pointing to a non writable directory goes with that philosophy. On Thu, Mar 19, 2015 at 5:58 PM, Stephan Beal sgb...@googlemail.com wrote: Presumably they don't expect users to use the shell, as the shell history is also (normally) saved in the home dir (except in some ultra-pedantic setups where the history is stored in a place where the user cannot access/edit it). - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Mar 19, 2015 11:24 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com wrote: But you're right, now that I think about it, is the only time I've ever seen a home directory not owned by the corresponding user but by root. Does the hosting service provide special commands for creating directories and files in your home directory? ___ 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 -- D. Richard Hipp d...@sqlite.org ___ 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 6:32 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Scott Robison sc...@casaderobison.com wrote: I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? That is the best answer I've been given. I explained how I worked (in both svn fossil) on separate branches in separate directories, but received no further feedback on that topic. -- Scott Robison ___ 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] home directory must be writeable
Here’s a thought: Someone on this list gave me the idea of aliasing “fossil” to “f”. I do it with a symlink instead of a shell alias so that it works even in places like a Vim :! command. Yeah, After writing yesterday's email, I worked another half hour, and ended up frustrated, so I did something similiar. That made the rest of the night more pleasant. In openshift you normally use git, but I actually love fossil, and as this is a personal project that has been running on a Raspberry for like 3 years, I won't touch git. Thanks On Thu, Mar 19, 2015 at 5:51 PM, Warren Young w...@etr-usa.com wrote: On Mar 18, 2015, at 5:08 PM, Abilio Marques abili...@gmail.com wrote: HOME=. ./fossil command Here’s a thought: Someone on this list gave me the idea of aliasing “fossil” to “f”. I do it with a symlink instead of a shell alias so that it works even in places like a Vim :! command. If you were willing to develop such a habit, you could do it with a shell script instead, which could always set HOME to someplace writeable. ___ 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] home directory must be writeable
Presumably they don't expect users to use the shell, as the shell history is also (normally) saved in the home dir (except in some ultra-pedantic setups where the history is stored in a place where the user cannot access/edit it). - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Mar 19, 2015 11:24 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com wrote: But you're right, now that I think about it, is the only time I've ever seen a home directory not owned by the corresponding user but by root. Does the hosting service provide special commands for creating directories and files in your home directory? ___ 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Does the git staging area provide any capability beyond this? Am I missing something? Please help me to understand why people think that the git staging area is a good idea. I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. See this: http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git The staging area can be disabled / skipped, but that's how it has been explained to me. -- Scott Robison ___ 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] Is this a crazy idea?
On 3/19/15, Scott Robison sc...@casaderobison.com wrote: I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? -- D. Richard Hipp d...@sqlite.org ___ 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] home directory must be writeable
On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com wrote: But you're right, now that I think about it, is the only time I've ever seen a home directory not owned by the corresponding user but by root. Does the hosting service provide special commands for creating directories and files in your home directory? ___ 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] home directory must be writeable
On Mar 19, 2015, at 4:14 PM, Abilio Marques abili...@gmail.com wrote: I actually didn't know about the ALL command. That changes the things. I believe I've gone over it every time I run fossil help, but never stopped to learn more about it, so thanks for opening my eyes. Yeah, “fossil all sync” is one of several features that make Fossil uncommonly nice to use. ___ 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] home directory must be writeable
Not that I'm aware of. I did some googling, and only found upset people, but no justification, nor any kind of special commands. On Thu, Mar 19, 2015 at 5:54 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Mar 19, 2015 at 6:14 PM, Abilio Marques abili...@gmail.com wrote: But you're right, now that I think about it, is the only time I've ever seen a home directory not owned by the corresponding user but by root. Does the hosting service provide special commands for creating directories and files in your home directory? ___ 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] home directory must be writeable
On Thu, Mar 19, 2015 at 5:45 PM, Richard Hipp d...@sqlite.org wrote: I remembered that change as having occurred years and years ago. But upon consulting the timeline, I see that Joe put it in two months ago. I don't recall the exact reason. Thanks Joe! This solves an annoyance for me. -- Scott Robison ___ 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] Is this a crazy idea?
On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? Am I missing something? Please help me to understand why people think that the git staging area is a good idea. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Is this a crazy idea?
This email has two motivations. First: Through the years I've evangelized about several subjects. Most of them go hand in hand with my philosophy that software tools (well, this is applicable to everything in life) should be as simple as possible for the task they are intended to be used. Actually is the user who must pick wisely. SQLite and Fossil are two of the greatest pieces of software I've come to use because of that reason. I've seen people (even myself a long time ago) using mysql server for applications with 4 tables and a single user until they hear about SQLite, and they never look back. Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Second (and the most important one): Several times I've toyed with the idea of writing a shim so fossil can be used in place of git or subversion. Instead of writing a new plugin for things like Qt Creator, Eclipse, TeXStudio and several others, task which is too wide and time consuming, I can make them believe they are running either git or subversion. In that way, any program compatible with git or subversion (by means of running the command line version) becomes compatible with fossil. I think that will open the door to hundreds of applications, and this way perhaps it will attract some new users to Fossil. Specially those in Windows, where git and svn are harder to install than just a simple exe download. I feel more comfortable writing the shim to GIT. Two reasons for that: first, I see git userbase growing (so I believe programs will favor GIT). Second, I've only used subversion in a couple of trivial situations. Having said these things, I must confess that in my mind, I find the staging area a difference that's not easily solved. Perhaps some of you have thought about this before, and have ideas on how to simulate it in a clean way. Any idea on my idea is welcomed. ___ 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] Is this a crazy idea?
I was cooking dinner, so Scott wrote it first. Basically I agree with his point of view. I must confess that historically, I first used fossil, then git, so staging was actually weird for me at the beginning. Then I kinda liked it for no apparent reason. It felt like it simplified the partial commit, specially because I decided this file SHOULD be in my next commit, this shouldn't... then went for lunch, came back... and the list was still there. I could go home, get back the next day, and the list was still there. In fossil, I must rewind all my work until the commit moment, check the list of files, remember what was did what, and the proceed to do a partial commit. Then there is the fact to ensure right things committed on the right branches. In my personal projects, there is one where I miss this thing a lot. I keep my resume in LaTeX, and I do push the PDFs that are generated, but only into trunk (not the other branches). I have to do partial commits all the times. Actually, about that, I've found myself in several other situations where I want to add everything except 1 or 2 files... So a commit --ignore these files would become handy. Specially because I can continue to do complete commits (of different files) while ignoring the same two, by repeating the command line on history, no changes at all, without having to think too much each time. Why staging area is so hip? I don't really know... I guess is a philosophy thing, and most people come from git, so they are used to it, and is a shock when they don't see it. I guess they feel like they will miss some kind of freedom. Can you survive on fossil without it? totally... For most of them (my git friends), the autosync is also a how will I survive this moment, but then they discover they can turn it off, use it for a while like that, then give it a shot again, and then live with it (some love it). On Thu, Mar 19, 2015 at 7:52 PM, Scott Robison sc...@casaderobison.com wrote: On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Does the git staging area provide any capability beyond this? Am I missing something? Please help me to understand why people think that the git staging area is a good idea. I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. See this: http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git The staging area can be disabled / skipped, but that's how it has been explained to me. -- Scott Robison ___ 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? AFAIK with git staging you can select specific changes in a single file as well, to commit only a sub-set of changes in that file. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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] Is this a crazy idea?
On 3/19/15, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? AFAIK with git staging you can select specific changes in a single file as well, to commit only a sub-set of changes in that file. *That* would be neat to have -- I've heard of it in git, but not explored it. The next time that I end up w/ two logical ideas commited w/ a single checkin won't be the first. Currently, if it's important enough for me, what I do is [stash] the commit, generate a diff and then selectively apply that diff in the appropriate number of steps, committing ea. logical idea at a time. Otherwise, re: staging area vs. fossil commit, it seems it's just a matter of default include vs default deny as far as what gets committed. One thing that would alleviate miscommitted collections of files (or miscommitted anything) is the ability to [pop] off a branch tip... -bch -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster(tm) F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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] 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
[fossil-users] Got Ubuntu PPA for fossil-releases up and running
I hope you don't mind that I got up an Ubuntu PPA for current fossil releases. This was merely a testing thing for me, to build learn how to handle a personal package archive - addiotionally it nagged me, that the currently shipped version of fossil in ubuntu is failry outdated. This PPA uses launchpad new automated build services, so it should give you the latest debs a little after I import the next stable release. Currently supported are the ubuntu-releases vivid, utopic and trusty. More info about the PPA on Launchpad: https://launchpad.net/~beowulfof/+archive/ubuntu/fossil-scm ppa:beowulfof/fossil-scm greetings Oliver ___ 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] Got Ubuntu PPA for fossil-releases up and running
Nice! Btw where can I see the build script that is fed to Launchpad's automated build services? Cheers. - Vikrant On 19 March 2015 at 17:01, Oliver Friedrich redtalonof+mailingl...@gmail.com wrote: I hope you don't mind that I got up an Ubuntu PPA for current fossil releases. This was merely a testing thing for me, to build learn how to handle a personal package archive - addiotionally it nagged me, that the currently shipped version of fossil in ubuntu is failry outdated. This PPA uses launchpad new automated build services, so it should give you the latest debs a little after I import the next stable release. Currently supported are the ubuntu-releases vivid, utopic and trusty. More info about the PPA on Launchpad: https://launchpad.net/~beowulfof/+archive/ubuntu/fossil-scm ppa:beowulfof/fossil-scm greetings Oliver ___ 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] Got Ubuntu PPA for fossil-releases up and running
These scripts are called recipes. I checked it in into my second branch that keeps the packaging information. The recipes that are actually used are only in launchpad and not stored in the repository itself, anyway, you can look at it here: https://bazaar.launchpad.net/~beowulfof/+junk/fossil-packaging/view/head:/debian/fossil.recipe I followed this very nice screencast of the launchpad team: https://www.youtube.com/watch?v=_bG-SXNX9Wwfeature=youtu.be Vikrant Chaudhary vikr...@webstream.io schrieb am Do., 19. März 2015 um 12:41 Uhr: Nice! Btw where can I see the build script that is fed to Launchpad's automated build services? Cheers. - Vikrant On 19 March 2015 at 17:01, Oliver Friedrich redtalonof+mailingl...@gmail.com wrote: I hope you don't mind that I got up an Ubuntu PPA for current fossil releases. This was merely a testing thing for me, to build learn how to handle a personal package archive - addiotionally it nagged me, that the currently shipped version of fossil in ubuntu is failry outdated. This PPA uses launchpad new automated build services, so it should give you the latest debs a little after I import the next stable release. Currently supported are the ubuntu-releases vivid, utopic and trusty. More info about the PPA on Launchpad: https://launchpad.net/~beowulfof/+archive/ubuntu/fossil-scm ppa:beowulfof/fossil-scm greetings Oliver ___ 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] same port in use by concurrent fossil instances
On 3/19/15, Tontyna tont...@ultrareal.de wrote: 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: The combination if IP address and TCP port must be unique. In this case, you have two instances of Fossil listening on the same TCP port, but using a different IP address. The fossil server is listening on the external IP address, apparently, and fossil ui is listening on the loopback address. HTTP requests from other machines should go to fossil server and HTTP requests from the local machine should go to fossil ui. At least that is the way I read this. 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 -- D. Richard Hipp d...@sqlite.org ___ 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] Is this a crazy idea?
By doing git commit -a, your doing an implicit git add -A before the commit, which stages all the uncommitted changes, and then you're working close to what you would in fossil. But we're talking about the Linus dream: You do some changes, then you select the files (not it seems that even line by line changes are selectable) you want to include in the commit by doing git add, and then you commit. Try this on an empty directory (I'm running by memory now, so don't believe me completely): git init echo line 1 test.txt git add test.txt git commit -m this is a test echo line 2 test.txt git status # You'll see it talks about unstaged changes by this point git commit -m another line in the test # I believe it will refuse On Thu, Mar 19, 2015 at 9:17 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430: (1) modify a file or files (2) add the files (every single time... this sucks sometimes, as Joerg said) (3) commit I'm not sure what (2) is unless you mean that I create new files in the working checkout and then use ``git add'' to add them. As to why this would suck, I'm not sure, isn't ``git add'' a necessary evil to get something into the repository? Here's my typical git day: (1) modify or create file(s) (1a) git add files if necessary (2) review changes with git diff (3) git commit -a (or git commit for a specific file if some changes are not ready (4) git pull; git push when ready So, let me ask this, if this means I'm using the staging area, why don't I feel like this is any different than how I use Fossil? Andy -- TAI64 timestamp: 4000550b7c54 ___ 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] Is this a crazy idea?
Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430: By doing git commit -a, your doing an implicit git add -A before the commit, which stages all the uncommitted changes, and then you're working close to what you would in fossil. I see, this is totally foreign to how I use git. I have never had to use ``git add -A'', nor have I had to do ``git add'' for files that were modified, only files that do not exist in the current checkout. You do some changes, then you select the files (not it seems that even line by line changes are selectable) you want to include in the commit by doing git add, and then you commit. Again, this is foreign to me. I'm not sure I see the benefit to such a feature. I can select which files (though not which lines) when I do ``fossil commit files.'' Having a step in between the commit and modifying the files just seems just more state that I have to worry about. git status # You'll see it talks about unstaged changes by this point Oh, yes, I do use ``git status'' similar to how I use ``fossil status'' git commit -m another line in the test # I believe it will refuse Yes, it will refuse. Normally, I just use git commit -a or git commit filename. So I think I can safely say that, no, I do not use the staging area, at least not the way Linus intended it. I think this is a non-feature. Thank you for taking the time to explain to me what I'm missing out on by using ``git commit -a'' and ``git commit filename'' :-) Andy -- TAI64 timestamp: 4000550b84b7 ___ 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] Is this a crazy idea?
Really? didn't know that... I'm impressed by that. There've been times when I've needed it, then proceeded to stash, then stash apply, then modified, then committed, then stash popped and so on... Unless you mean that you do a git add, the modify the same file, and commit as is, without doing git add again... that way you can selectively commit a sub-set, but depends on the moment you did the adds. Never heard of selectivity. I know it could be off topic (does it?), but how would you do that? Do you have an example? On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? AFAIK with git staging you can select specific changes in a single file as well, to commit only a sub-set of changes in that file. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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] Is this a crazy idea?
Thus said Abilio Marques on Thu, 19 Mar 2015 19:22:14 -0430: Having said these things, I must confess that in my mind, I find the staging area a difference that's not easily solved. Perhaps some of you have thought about this before, and have ideas on how to simulate it in a clean way. Any idea on my idea is welcomed. I've used git for a few years now, but I've never used this beloved ``staging area,'' at least not conciously. What am I missing by not using the ``staging area?'' Andy -- TAI64 timestamp: 4000550b78ab ___ 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] Is this a crazy idea?
I think I missed you here, or you missed me, but I know you got the fact that by doing: git commit -a or git commit filename, you're skipping the staging area. For example, by doing git commit -a -m this is a test, what git is internally doing is the equivalent to: git add -A git commit -m this is a test And by doing git commit -m this is a test filenames, it's doing: git add filenames git commit -m this is a test I suggest you (if you haven't done it) to avoid using git commit - and avoid using git commit filenames . The way you're working, well... that was the way I did it the first days I used git, until a close friend of mine told me to drop it and work like everybody else. I said no, 3 minutes later I was trying... had to learn that the ADD command was for something else that adding a new file (linus tovards, why? just use the word STAGE). Believe me, reading about staging area seemed weird and hard to grasp... why would I complicate with those things? In the end I learned how to use it, and it improved communication with my team. That's the reason why I tell you to give it a shot. On Thu, Mar 19, 2015 at 9:53 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Abilio Marques on Thu, 19 Mar 2015 21:25:05 -0430: By doing git commit -a, your doing an implicit git add -A before the commit, which stages all the uncommitted changes, and then you're working close to what you would in fossil. I see, this is totally foreign to how I use git. I have never had to use ``git add -A'', nor have I had to do ``git add'' for files that were modified, only files that do not exist in the current checkout. You do some changes, then you select the files (not it seems that even line by line changes are selectable) you want to include in the commit by doing git add, and then you commit. Again, this is foreign to me. I'm not sure I see the benefit to such a feature. I can select which files (though not which lines) when I do ``fossil commit files.'' Having a step in between the commit and modifying the files just seems just more state that I have to worry about. git status # You'll see it talks about unstaged changes by this point Oh, yes, I do use ``git status'' similar to how I use ``fossil status'' git commit -m another line in the test # I believe it will refuse Yes, it will refuse. Normally, I just use git commit -a or git commit filename. So I think I can safely say that, no, I do not use the staging area, at least not the way Linus intended it. I think this is a non-feature. Thank you for taking the time to explain to me what I'm missing out on by using ``git commit -a'' and ``git commit filename'' :-) Andy -- TAI64 timestamp: 4000550b84b7 ___ 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] Is this a crazy idea?
will only commit changes in 1, and if you do git status, will tell you about the modifications done in 3. On Thu, Mar 19, 2015 at 8:38 PM, Richard Hipp d...@sqlite.org wrote: Further questions about staging area: If I do this: (1) Edit file xyzzy.txt (2) git add xyzzy.txt (3) More edits to xyzzy.txt (4) git commit Then does only the first set of edits to xyzzy.txt get committed, or do both edits (1) and (3) get committed? -- D. Richard Hipp d...@sqlite.org ___ 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 06:22:52PM -0600, Scott Robison wrote: I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Ironically, from what I have seen it is the feature most likely to make you commit something you didn't mean to. It is even more obnoxious than the commit with explicit file list in all other systems -- it makes it even easier to forgot parts with a dirty work directory. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] multiple independent check-outs against the same repository
After reading Mr. Hipp answer to some previous email about git saying: So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? I started to think: what does it mean to have multiple independent check-outs? And I knew I wouldn't be able to sleep well because of not knowing. So I created a new test repo, and began: mkdir test cd test fossil new test.fossil mkdir a b cd a fossil open ../test.fossil echo file a a.txt cd .. cd b fossil open ../test.fossil echo file b b.txt cd .. fossil status # replied not within an open checkout Then went to commit in each subdirectory... then did a status... both reflected the check-ins in the correct order... and the other directories weren't there. Actually going to a (the first commited one) and running fossil update trunk did: ADD b.txt REMOVE a.txt So far seems magic, as I don't seem to grasp the power, uses and implications for it. Is there any documentation? This is my first approach to what Mr. Hipp said. Am I mistaken? ___ 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] Is this a crazy idea?
I'm brand new to fossil but have used git some and mercurial even longer. When I'm working on a project I tend to poke around in the areas of code nearby to what my task directly involves - as a manner of investigating and learning. The git staging area is useful to my workflow because I am often making changes and testing something, but later decide to have separate commits within all the changes. This helps preserve a nicer history where commits usually have single-responsibility. For example, fixing a null pointer in a button click handler, but also tweaking the button's sizing/border/etc. to be consistent within the UI. I would likely make those two changes at once and test locally, but ultimately have separate commits for each change. On other occasions where I might end up in a similar situations is when finding out one bug is actually multiple bugs. It sounds like fossil is similar to mercurial - mercurial's commit command by default includes all local changes, but arguments can be specified for including/excluding files (or file patterns). When I first started using git I was thrown off by having to include things into staging before committing, but I have started preferring the explicit nature of defining my commits that way. Christopher ___ 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] Is this a crazy idea?
Further questions about staging area: If I do this: (1) Edit file xyzzy.txt (2) git add xyzzy.txt (3) More edits to xyzzy.txt (4) git commit Then does only the first set of edits to xyzzy.txt get committed, or do both edits (1) and (3) get committed? -- D. Richard Hipp d...@sqlite.org ___ 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] Is this a crazy idea?
Further questions about staging area: If I do this: (1) Edit file xyzzy.txt (2) git add xyzzy.txt (3) More edits to xyzzy.txt (4) git commit Then does only the first set of edits to xyzzy.txt get committed, or do both edits (1) and (3) get committed? Only changes from step 1 are committed. After adding changes from step 1 to staging area then making more changes, a status looks like this: Changes to be committed: modified: index.js Changes not staged for commit: modified: index.js ___ 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] Is this a crazy idea?
Do you follow the traditional?: (1) modify a file or files (2) add the files (every single time... this sucks sometimes, as Joerg said) (3) commit If the answer is yes, you're using the staging area... Cool things about that... yes, you can select what to include (seems that line by line). See my next email On Thu, Mar 19, 2015 at 9:01 PM, Andy Bradford amb-sendok-1429407112.filllmkhpgbjfacbk...@bradfords.org wrote: Thus said Abilio Marques on Thu, 19 Mar 2015 19:22:14 -0430: Having said these things, I must confess that in my mind, I find the staging area a difference that's not easily solved. Perhaps some of you have thought about this before, and have ideas on how to simulate it in a clean way. Any idea on my idea is welcomed. I've used git for a few years now, but I've never used this beloved ``staging area,'' at least not conciously. What am I missing by not using the ``staging area?'' Andy -- TAI64 timestamp: 4000550b78ab ___ 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] Is this a crazy idea?
Yes, I realized you seem to be right and nobody told me (I learnt git on my own), but in git, you can run git add --interactive (and it allows you to selectively work with each uncommitted add you did) and there is also git add --edit, which allows you to directly edit the unified patch in your favorite text editor (the one that will be stored in the commit). Seems REALLY powerful, but need to play more with it. As a side note, one of the reasons I dislike git is because the commands don't do (do as in never) what their name imply, and some are hidden as subcommands inside commands that are meant for other purposes. Fossil should keep away from that road of uncertainty. On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? AFAIK with git staging you can select specific changes in a single file as well, to commit only a sub-set of changes in that file. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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] Is this a crazy idea?
On Mar 19, 2015, at 5:52 PM, Abilio Marques abili...@gmail.com wrote:
I've toyed with the idea of writing a shim so fossil can be used in place
of git or subversion.
I speak only pidgin Git, so I wouldn’t like to speculate about how difficult
such a shim would be to write.
I can, however, speak to the svn case. I have used Subversion heavily for
about a dozen years now, so I can pretty confidently predict that you’re going
to run into a bunch of areas where the semantics of Fossil and Subversion
differ enough to make building such a shim tricky, and in places actually
difficult.
Here are the differences that immediately occur to me:
1. svn uses a monotonically-increasing revision number for the whole repository
as the unique identifier for each checkin. Fossil uses cryptographic hashes
instead. This affects every command in both systems that take an -r flag, and
more.
(“More” because Fossil doesn’t always use -r to specify a checkin. Fossil is
somewhat of a bicameral mind on this point: sometimes you use -r, and other
times you just give it as a bare parameter.)
For the same reason, I don’t know how you’d implement an svnversion wrapper in
terms of Fossil.
2. Fossil branching and tagging are baked into the database schema; there’s
only one way to do it.
In Subversion, branching and tagging are a mere *convention* built on top of
the svn copy command, and there is no requirement that your copy target be
somewhere under the repo’s branches or tags directories; that too is just a
convention.
I don’t think you can actually emulate the full scope of the svn copy command
in terms of Fossil. There are things you can do with that command that do not
map neatly to fossil tag and branch commands.
3. fossil timeline is not quite the same thing as svn log.
First you have to decide if you want to translate the output formats so that
it’s parseable by tools that know how to read svn log output.
Then you have a deeper problem, which is that the two commands simply don’t
entirely overlap in their capability.
Some svn log commands will be straightforward to translate into fossil timeline
commands:
svn log -r{2014-12-25}:HEAD
is the same as:
fossil timeline after 2014-12-25 -n 0
But, svn also lets me give an arbitrary log endpoint, which fossil timeline
doesn’t:
svn log -r{2014-12-25}:r1234
How will your shim cope?
4. svn does one-step mv and rm operations. Fossil currently requires a
separate OS-level mv or rm to accompany the Fossil command in order to make the
file tree consistent with the repo.
I’ve advocated for this to change, though it’s looking like if something along
this line does happen, it won’t be to make Fossil behave exactly like svn, but
perhaps more like Monotone instead.
5. svn ci is not quite the same thing as fossil ci. Perhaps “fossil ci .” is
close enough for your purposes. (i.e. Subversion checks in only files in the
current directory and its children, by default.)
6. svn allows sub-repo checkouts. Fossil doesn’t. (Yet.)
7. There is no equivalent to svn [un]lock in Fossil. (Praise Ritchie!)
8. Emulating svn merge in terms of fossil merge amounts to taking a simple and
straightforward interface and complexifying it.
9. svn doesn’t even blink if you try to check in a binary file. Fossil copes
just fine with binary files, too, but by default it second-guesses you whenever
you do it with a file that isn’t on its glob whilelist.
10. svn info more or less combines what Fossil implements separately via info
and finfo. I think it might be tricky to work out which Fossil command to call
for a given set of args to your svn wrapper.
11. svn stat and fossil stat are conceptually the same thing, but their output
formats are quite different.
12. fossil open kind of overlaps the effects of svn co and svn switch, but not
entirely.
13. Most of the svn prop{get,set,edit,del} properties do not exist in Fossil:
svn:ignore: Fossil has the ignore-glob setting, but it’s very much not the same
thing. Fossil and svn are almost inverses in the way they handle file
ignorance. (Ignoration? Ignorification?)
svn:keywords: Fossil doesn’t do RCS/CVS-like keyword substitution at all, on
purpose.
svn:executable: A similar per-file property exists in Fossil, but it’s more of
an implicit property. To make the shim behave *exactly* like svn, you’re going
to have to defeat Fossil’s implicit use of the file’s modes to implement this
property.
svn:eol-style: Fossil doesn’t do CRLF translation, ever. I think those
interested in using such a shim will be a self-selected set of people who have
a greater-than-average interest in having such a feature than those willing to
just switch to Fossil. You may be asked to emulate this behavior on top of
Fossil.
svn:mime-type: The “doc” URL handler in Fossil has a hard-coded implementation
of this, which probably obviates the need to emulate this property, but perhaps
someone
Re: [fossil-users] multiple independent check-outs against the same repository
On 3/19/15, Abilio Marques abili...@gmail.com wrote: After reading Mr. Hipp answer to some previous email about git saying: So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? I started to think: what does it mean to have multiple independent check-outs? And I knew I wouldn't be able to sleep well because of not knowing. So I created a new test repo, and began: mkdir test cd test fossil new test.fossil mkdir a b cd a fossil open ../test.fossil echo file a a.txt cd .. cd b fossil open ../test.fossil echo file b b.txt cd .. fossil status # replied not within an open checkout Then went to commit in each subdirectory... then did a status... both reflected the check-ins in the correct order... and the other directories weren't there. Actually going to a (the first commited one) and running fossil update trunk did: ADD b.txt REMOVE a.txt So far seems magic, as I don't seem to grasp the power, uses and implications for it. Is there any documentation? This is my first approach to what Mr. Hipp said. Am I mistaken? You are doing it right. There is no documentation because I could not conceive of wanting to use a VCS in any other way. Scenario: You want to compare the performance of two different versions of the project. So you do two simultaneous checkouts, in separate directories, and run speed tests on each. Scenario: You in the middle of a big change when a support request from a customer comes in that requires you to work on a release from a year ago. No need to stash all the changes you are in the middle of, just open the older version in a separate directory - make changes there and branch it if necessary, then go back to what you were doing. Scenario: Do simultaneous builds with different compile-time options for the same version of the code in three separate directories. Scenario: Work on four separate branches, all at the same time, located in four separate directories. Scenario: Be editing code in a branch while simultaneously running a bisect is on trunk. And so forth -- D. Richard Hipp d...@sqlite.org ___ 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] multiple independent check-outs against the same repository
On 3/19/15, Abilio Marques abili...@gmail.com wrote: PS: after running my quick test in fossil 1.31, I ended with two separate artifacts, both on trunk, but without a common ancestor. I'm running Ubuntu, and I haven't compiled the 1.32. I believe that version was released as a patch for this common ancestor issue. Will my test behave differently on 1.32? Yes, that is yet another failing of the ill-conceived patch that allows fossil init to create a repository without an initial check-in. I rue the day that I allowed that patch to land on trunk. But it is all fixed now - you won't have the problem with 1.32. -- D. Richard Hipp d...@sqlite.org ___ 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] Is this a crazy idea?
die.drachen wrote: The git staging area is useful to my workflow because I am often making changes and testing something, but later decide to have separate commits within all the changes. This helps preserve a nicer history where commits usually have single-responsibility. For example, fixing a null pointer in a button click handler, but also tweaking the button's sizing/border/etc. to be consistent within the UI. I would likely make those two changes at once and test locally, but ultimately have separate commits for each change. On other occasions where I might end up in a similar situations is when finding out one bug is actually multiple bugs. There are three points I'd like to make here: First, the safer (and arguably overall better) approach is to recognize that stash/shelve operations are the inverse of the staging area for this purpose. I.e., rather than stage a partial commit, you stash everything but the partial commit, then commit whatever changes remain in toto. This does not require the staging area and ensures that, e.g., you're not committing something that doesn't even compile (which breaks bisect, CI tools, etc.). Second, even if you prefer not to do it this way, git commit --amend essentially made the staging area superfluous a long time ago for the purpose of splitting commits. Third, while splitting commits (where you accidentally mashed multiple things together that you later realize should be separated) is a very relevant feature, this is largely a problem of the user interface, not the staging area. The staging area is frequently used because many graphical Git clients provide excellent UI tooling for staging parts of a file as a commit. However, this does not require a staging area; see, e.g., Bazaar's qshelve command for a graphical tool that provides a similar feature for stashing partial commits. It sounds like fossil is similar to mercurial - mercurial's commit command by default includes all local changes, but arguments can be specified for including/excluding files (or file patterns). Keep in mind that Mercurial also has Mercurial queues, which is (for better or worse) a staging area on steroids. Also, what I said about git commit --amend above applies equally to hg commit --amend. Reimer Behrends ___ 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] Is this a crazy idea?
Abilio Marques wrote: Cool things about that... yes, you can select what to include (seems that line by line). This does not require a staging area. Darcs, for example, had such selective commits since its inception (in fact, it was and is the default mode of operation for Darcs, for better or worse). Reimer Behrends ___ 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 6:10 PM, Abilio Marques abili...@gmail.com wrote: Really? didn't know that... I'm impressed by that. There've been times when I've needed it, then proceeded to stash, then stash apply, then modified, then committed, then stash popped and so on... Unless you mean that you do a git add, the modify the same file, and commit as is, without doing git add again... that way you can selectively commit a sub-set, but depends on the moment you did the adds. Never heard of selectivity. I know it could be off topic (does it?), but how would you do that? Do you have an example? I actually do not know how to do it from the command line. What I use is the git gui command (*), which is a light Tk interface to essentially look at the workspace and the staging area, with a list of files to the left, modified, new, deleted, and for modified files I see the unified diff of my changes for the selected file. I use that to go through all the changes, review them, and choose which to place into the commit, whole file, chunks, parts of a chunk (stage file, stage chunk, stage lines). How it does all this underneath, i.e. which other git commands get used and how, that I do not know. (*) Note, git gui is not gitk, although each can invoke the other, as a separate process. On Thu, Mar 19, 2015 at 8:28 PM, Andreas Kupries andre...@activestate.com wrote: On Thu, Mar 19, 2015 at 5:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Fossil does give you the ability to do a partial commit (in case you are really want to commit changes that you have not tested). Just list the subset of files you want to commit on the commit command-line: fossil commit one.txt two.txt dir-three/ If you include directories in the list, then all modified files underneath those directories are committed. Does the git staging area provide any capability beyond this? AFAIK with git staging you can select specific changes in a single file as well, to commit only a sub-set of changes in that file. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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] Is this a crazy idea?
Thus said Abilio Marques on Thu, 19 Mar 2015 22:10:41 -0430: git commit -a or git commit filename, you're skipping the staging area. Yes, that's right---thanks to your explanation. I haven't needed it and now that I understand it (at least according what has been discussed) I'm certain I don't need it. :-) I suggest you (if you haven't done it) to avoid using git commit -a and avoid using git commit filenames. Why? Based on what I've seen so far, it doesn't really benefit me (and I fail to see how my use of it will benefit others). Thanks, Andy -- TAI64 timestamp: 4000550b909e ___ 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] multiple independent check-outs against the same repository
I imagined some of those scenarios right away after my experiment... Some are great... Until today, I was doing a fossil clone file:// or ssh:// ... Now I can deal with just a single copy of the repo. I only see it quickly and indirectly mentioned in section 2.3 here: http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki But the text in there doesn't tease me to try new things not available in other VCS. Plus, is kinda hidden, so it ain't obvious you can do it that way. Is it possible to do describe it somewhere for future reference? PS: after running my quick test in fossil 1.31, I ended with two separate artifacts, both on trunk, but without a common ancestor. I'm running Ubuntu, and I haven't compiled the 1.32. I believe that version was released as a patch for this common ancestor issue. Will my test behave differently on 1.32? On Thu, Mar 19, 2015 at 10:57 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: After reading Mr. Hipp answer to some previous email about git saying: So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? I started to think: what does it mean to have multiple independent check-outs? And I knew I wouldn't be able to sleep well because of not knowing. So I created a new test repo, and began: mkdir test cd test fossil new test.fossil mkdir a b cd a fossil open ../test.fossil echo file a a.txt cd .. cd b fossil open ../test.fossil echo file b b.txt cd .. fossil status # replied not within an open checkout Then went to commit in each subdirectory... then did a status... both reflected the check-ins in the correct order... and the other directories weren't there. Actually going to a (the first commited one) and running fossil update trunk did: ADD b.txt REMOVE a.txt So far seems magic, as I don't seem to grasp the power, uses and implications for it. Is there any documentation? This is my first approach to what Mr. Hipp said. Am I mistaken? You are doing it right. There is no documentation because I could not conceive of wanting to use a VCS in any other way. Scenario: You want to compare the performance of two different versions of the project. So you do two simultaneous checkouts, in separate directories, and run speed tests on each. Scenario: You in the middle of a big change when a support request from a customer comes in that requires you to work on a release from a year ago. No need to stash all the changes you are in the middle of, just open the older version in a separate directory - make changes there and branch it if necessary, then go back to what you were doing. Scenario: Do simultaneous builds with different compile-time options for the same version of the code in three separate directories. Scenario: Work on four separate branches, all at the same time, located in four separate directories. Scenario: Be editing code in a branch while simultaneously running a bisect is on trunk. And so forth -- D. Richard Hipp d...@sqlite.org ___ 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] Is this a crazy idea?
Thus said Abilio Marques on Thu, 19 Mar 2015 21:08:55 -0430: (1) modify a file or files (2) add the files (every single time... this sucks sometimes, as Joerg said) (3) commit I'm not sure what (2) is unless you mean that I create new files in the working checkout and then use ``git add'' to add them. As to why this would suck, I'm not sure, isn't ``git add'' a necessary evil to get something into the repository? Here's my typical git day: (1) modify or create file(s) (1a) git add files if necessary (2) review changes with git diff (3) git commit -a (or git commit for a specific file if some changes are not ready (4) git pull; git push when ready So, let me ask this, if this means I'm using the staging area, why don't I feel like this is any different than how I use Fossil? Andy -- TAI64 timestamp: 4000550b7c54 ___ 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] Is this a crazy idea?
Thus said Abilio Marques on Thu, 19 Mar 2015 21:29:28 -0430: As a side note, one of the reasons I dislike git is because the commands don't do (do as in never) what their name imply, and some are hidden as subcommands inside commands that are meant for other purposes. You mean like overloading ``git add'' to be both ``git add'' for new files to be added to the checkout (and eventually the repository) and using ``git add'' to really mean ``git stage''? Andy -- TAI64 timestamp: 4000550b8522 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Convenient command for standardizing and simplifying marking a commit as a mistake.
Hi, I wonder why there isn't a command for simplifying the process of marking a commit as a mistake. So with a single command, fossil will: *Move the commit and its derived commits to mistake branch. *If there is a leaf in the branch, the leaf will be closed. *The mistaken commits will be hidden from the timeline. *If any of the mistaken commits have been merged into another branch, the mistaken commits will be backed out from the valid branches. *. (Perhaps some other stuffs I may not have thought about at the moment.) Let me know what you guys think about it. Thanks. Henry smime.p7s Description: S/MIME cryptographic signature ___ 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] home directory must be writeable
Yeah, I know home directory MUST be writable. I do fight with that all the time. I've always guessed is some sort of weird security thing. Never asked. I'm not asking fossil to change because of that. As you say, is an OpenShift issue. Just thought fossil was of better use without global config that not usable at all. But you're right, now that I think about it, is the only time I've ever seen a home directory not owned by the corresponding user but by root. Even when I knew about the global config, I actually didn't know about the ALL command. That changes the things. I believe I've gone over it every time I run fossil help, but never stopped to learn more about it, so thanks for opening my eyes. On Thu, Mar 19, 2015 at 4:14 PM, Warren Young w...@etr-usa.com wrote: On Mar 18, 2015, at 5:04 PM, Abilio Marques abili...@gmail.com wrote: *home directory /var/lib/openshift/54fb48714382ecec88eb/ must be writeable* That sounds like just cause to complain to OpenShift tech support. There’s no good justification for $HOME to be read-only on a web platform provider. You’re renting that space. I see it writes a .fossil file (sqlite database), but is it that important? According to this, yes, it’s somewhat important: http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki By giving Fossil a place to write that file, you give it a place to store global settings and to remember which Fossils it has opened, so that commands like “fossil all sync” work as expected. ___ 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
On Thu, Mar 19, 2015 at 11:53 AM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote: On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote: On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: Content-Encoding: gzip Content-Length: 1516 So the question becomes: Should the Content-Length be the length of the content before or after compression? Before aka after decompression. Can you provide support for this assertion? Hm. Reading RFC 2616 again, I think I have to retract that. See the last paragraph of 4.4. I've also been reading in RFC 7230. The more I read, the more I believe this is a Chrome bug. I think there is some confusion of Content-Encoding vs Transfer-Encoding From RFC7230, section3.3.1: Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response chain MAY decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding changes are made to the Transfer-Encoding field-value. From this, I would interpret Content-Length as being the size, in octets, of the content after Content-Encoding is applied. Further, section 3.3.2 says: A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field. To me, this reinforces my above interpretation of Content-Length My guess would a proxy bug. Albert's recent messages seem to support this. ___ 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
On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: Content-Encoding: gzip Content-Length: 1516 So the question becomes: Should the Content-Length be the length of the content before or after compression? Fossil inherited the code for this from CVSTrac, which has always set the Content-Length to be the number of bytes of content sent over the wire (the size after compression). And that interpretation has never before given trouble in 13 years of prior use. The W3C documentation on the issue is ambiguous and confused. A web search shows numerous discussions of the problem with lots of debate on both sides and no clear resolution of the issue. Though I did find https://bugs.php.net/bug.php?id=44164 which seems to imply that Fossil is doing it correctly. In the absence of additional information, therefore, I'm going to call this a bug in Chrome. -- D. Richard Hipp d...@sqlite.org ___ 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
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote: On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: Content-Encoding: gzip Content-Length: 1516 So the question becomes: Should the Content-Length be the length of the content before or after compression? Before aka after decompression. Can you provide support for this assertion? -- D. Richard Hipp d...@sqlite.org ___ 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 19.03.2015 um 00:01 schrieb a...@gmx-topmail.de: Am 18.03.2015 um 00:28 schrieb Tontyna: 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'. Yes, I would like to try that on my machine... Thanks to Tontya, who sent such a precompiled binary to me I could now get some steps forward in understanding the problem. When looking at the leftover textfiles there is no difference between the files sent to firefox and those sent to the other browsers. But I found that these are gzip compressed with headers like this: HTTP/1.0 200 OK Date: Thu, 19 Mar 2015 12:48:01 GMT Connection: close X-UA-Compatible: IE=edge X-Frame-Options: SAMEORIGIN Cache-control: no-cache Content-Type: text/html; charset=utf-8 Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 1516 My first idea was that I'd try what happens when I'd disable gzip compression on the server side, but found no switch for that in fossil (is there any?). When I disabled gzip compression on the client side (for chrome I did change the accept-encoding header with the modheader extension) it turned out that now I receive complete pages again. When I extracted Content-Length bytes of the files with the uncompressed html-code with something like: tail -114 fossil_server_P8080__out28.txt | head -c 1516 (first tail cuts out the header), I got exactly that truncated part of the page source that chrome (and ie and opera) report when looking at the truncated page sources. So it looks like these browsers (or any component that does the uncompress, at least on my machine?!?) interpret the content length as the length of the uncompressed content and cut off the rest (probably some kind of security measure?) while firefox either ignores the Content-Length or interprets it as the length of the compressed content. I don't know what the official specs are concerning Content-Length and whether the one or the other behavior is correct, why it has changed on my machines about two weeks ago and I wonder even more that no one else sees these problems. But I do now have another workaround (switch of compression which is probably even advantageous when looking at local repos), so for me the problem has lost urgency a lot and it seems to be exoctic when it's just me who has it, so I can understand if you decide to ignore it. But if anyone with more knowledge about the details of http details wants to investigate this further, I will be happy to provide any further details that would help to fully understand what goes wrong and if fossil can (should?) do anything about it. Thanks for your help and thanks for fossil, Albert PS: I was asked to prepare a public repository so others could have a look at it. As I (and I think at least also Tontyna) now believe that the problem isn't with the repository my impression is this probably is not necessary anymore. But if that impression is wrong I could now create such a public repository and send the IP and port to those who asked and who'd still like to have a look at it ___ 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
On 14.03.2015 13:12, a...@gmx-topmail.de wrote: I am having problems to access my local fossil repositories with a recent versions of chrome, it looks like only part of the html code is served by the standalone webserver. My question is whether this is a known problem and others can verify it with a similar setup. Is there a virus scanner sitting between the network and the browser, like a local proxy? -- tsbg ___ 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
On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote: On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: Content-Encoding: gzip Content-Length: 1516 So the question becomes: Should the Content-Length be the length of the content before or after compression? Before aka after decompression. Joerg ___ 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
On Thu, Mar 19, 2015 at 12:56:02PM -0400, Ron W wrote: I think there is some confusion of Content-Encoding vs Transfer-Encoding Content-Encoding is gzip, Transfer-Encoding should be unset as Fossil doesn't do HTTP/1.1 Chunked Transfers. Joerg ___ 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
On Thu, Mar 19, 2015 at 4:53 PM, Richard Hipp d...@sqlite.org wrote: I've also been reading in RFC 7230. The more I read, the more I believe this is a Chrome bug. http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 is pretty unambiguous: The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. That's the transfer-length (which fossil doesn't set IIRC), followed by this note: If a Content-Length header field (section 14.13 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different i.e. Content-length == transfer-length, _after_ any transfer encoding (compression). Section 14.13 says: The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient i concur that it's a bug in the OP's Chrome version. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Possible Bug in Merge Conflict Blocks
On Thu, Mar 19, 2015 at 9:32 AM, bch brad.har...@gmail.com wrote: The reality is that nothing can be perfect for 100% of all possible use cases, and in this particular case, I just got unlucky. The merge conflict information as given couldn't support a mechanical pick one or the other resolution (which was fine because this particular merge needed a thought out solution, not a mechanical resolution). This is what I was leaning toward. I'm inclined to just leave it alone and live with the reality. Sorry for yelling fire (or whatever). Thanks for filling a reasonable report - I think the next step is developing a *workflow* that illustrates what's going on: i.e.: select you edits, run a diff to see what the changes really are. One thing that struck me is that code references (i.e.: last common ancestor) could stand to have their SHA1 identifier included in the header so I've got it for immediate reference. And to be clear that's the sort of thing I do (and what is typically necessary). As I've thought more about it, I think the reason for the disconnect for me in my head (not having dealt much with merge conflicts in the past) is that the merge conflict block greatly resembles a diff between two revisions, yet it is not a traditional diff (and thus does not replace the need for actual analysis via traditional diff between the baseline each of the two descendants, possibly more). No biggie. Just a little embarrassment for crying wolf. But the good thing is that I understand the merging code and rationale a lot better now than I did 24 hours ago. :) -- Scott Robison ___ 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
On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote: On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote: On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: Content-Encoding: gzip Content-Length: 1516 So the question becomes: Should the Content-Length be the length of the content before or after compression? Before aka after decompression. Can you provide support for this assertion? Hm. Reading RFC 2616 again, I think I have to retract that. See the last paragraph of 4.4. Joerg ___ 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
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 ___ 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] home directory must be writeable
On Mar 18, 2015, at 5:04 PM, Abilio Marques abili...@gmail.com wrote: home directory /var/lib/openshift/54fb48714382ecec88eb/ must be writeable That sounds like just cause to complain to OpenShift tech support. There’s no good justification for $HOME to be read-only on a web platform provider. You’re renting that space. I see it writes a .fossil file (sqlite database), but is it that important? According to this, yes, it’s somewhat important: http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki http://fossil-scm.org/index.html/doc/trunk/www/tech_overview.wiki By giving Fossil a place to write that file, you give it a place to store global settings and to remember which Fossils it has opened, so that commands like “fossil all sync” work as expected.___ 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 19.03.2015 um 15:19 schrieb Thomas Schnurrenberger: On 14.03.2015 13:12, a...@gmx-topmail.de wrote: I am having problems to access my local fossil repositories with a recent versions of chrome, it looks like only part of the html code is served by the standalone webserver. My question is whether this is a known problem and others can verify it with a similar setup. Is there a virus scanner sitting between the network and the browser, like a local proxy? yes, I think so. But it was one of my first tries to check whether I'd see the problem also when switching off the virus-protection and firewall. It did not change things for me then, but honestly I'm always somewhat unsure if I really did switch off everything on Windows systems when the corresponding GUIs tell me so. So I'll probably try that again... 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] fossil ui not working with recent chrome browser
On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote: On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote: On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: Content-Encoding: gzip Content-Length: 1516 So the question becomes: Should the Content-Length be the length of the content before or after compression? Before aka after decompression. Can you provide support for this assertion? Hm. Reading RFC 2616 again, I think I have to retract that. See the last paragraph of 4.4. I've also been reading in RFC 7230. The more I read, the more I believe this is a Chrome bug. -- D. Richard Hipp d...@sqlite.org ___ 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] Possible Bug in Merge Conflict Blocks
On Mar 19, 2015 12:40 AM, Scott Robison sc...@casaderobison.com wrote: On Wed, Mar 18, 2015 at 5:41 PM, bch brad.har...@gmail.com wrote: I tried this, and I see what you're talking about -- It's not clear to me it's an error (I'm not apologizing for anything that happened here, but I'd have to better understand the merge algorithm to know if this is logically sane). Its easy to see how this could be confusing though. I'll have to fiddle more to understand this. Okay, here's what I have come up with. 1. It is not a bug. It is technically accurate, though confusing, because it doesn't allow you to easily use original or use merge because of the missing line. 2. The problem (in my expectation, not fossil) is one of context. I made a little test change to force at least one extra line of context at the end of the conflict block and that gives me what I was expecting. However, I can see where this problem could probably crop up with inadequate context at the beginning of the conflict instead of at the end, or that perhaps one extra line of context still wouldn't be enough, or could even be too much. The reality is that nothing can be perfect for 100% of all possible use cases, and in this particular case, I just got unlucky. The merge conflict information as given couldn't support a mechanical pick one or the other resolution (which was fine because this particular merge needed a thought out solution, not a mechanical resolution). This is what I was leaning toward. I'm inclined to just leave it alone and live with the reality. Sorry for yelling fire (or whatever). Thanks for filling a reasonable report - I think the next step is developing a *workflow* that illustrates what's going on: i.e.: select you edits, run a diff to see what the changes really are. One thing that struck me is that code references (i.e.: last common ancestor) could stand to have their SHA1 identifier included in the header so I've got it for immediate reference. SDR ___ 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 19.03.2015 um 16:53 schrieb Richard Hipp: On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 10:16:18AM -0400, Richard Hipp wrote: On 3/19/15, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Mar 19, 2015 at 09:59:24AM -0400, Richard Hipp wrote: On 3/19/15, a...@gmx-topmail.de a...@gmx-topmail.de wrote: Content-Encoding: gzip Content-Length: 1516 So the question becomes: Should the Content-Length be the length of the content before or after compression? Before aka after decompression. Can you provide support for this assertion? Hm. Reading RFC 2616 again, I think I have to retract that. See the last paragraph of 4.4. I've also been reading in RFC 7230. The more I read, the more I believe this is a Chrome bug. honestly, I think that there is some other component or some special settings on my computer which is buggy or wrong, not chrome as such (especially as opera and ie have the same problem, and all only on my computer). I'd imagine that there'd be storm of protest we'd be aware of if the latest release of chrome would show incomplete pages for every compressed http content it tries to show :-) Most plausible seems something like the virus scanner which might uncompress to see what's in the content. As I mentioned elsewhere switching that off was one of the first things I tried (even before reporting here) but that didn't help then. But I think I should check that once more, and probably there are other components on my system which think they also need to look into my http traffic... I think if you're reasonably sure that fossil is doing the correct thing and I'm the only one that is seeing it then there is no reason to change anything. Sorry if I have created unnecessary fuss with my question... Albert ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
