Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file
On Wed, Nov 12, 2014 at 10:16 PM, to...@acm.org wrote: When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. That's apparently a bug (and thank you for the reproduction steps), but i've gotta ask: why on earth would have a read-only file under fossil's control (as opposed to having read-only generated files, which i do to keep me from accidentally editing the generated Makefiles instead of their input tempates)? Fossil doesn't store/set any attributes except +x (git doesn't support other attributes either (anymore), based on what i've read). -- - 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: Failure to acknowledge changes after failing to overwrite write-protected file
On Nov 13, 2014 7:20 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Nov 12, 2014 at 10:16 PM, to...@acm.org wrote: When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. That's apparently a bug (and thank you for the reproduction steps), but i've gotta ask: why on earth would have a read-only file under fossil's control (as opposed to having read-only generated files, which i do to keep me from accidentally editing the generated Makefiles instead of their input tempates)? I think I could imagine this (on Unix) if I'm developing as bch but testing as root (ie: I need elevated access to petrol something, maybe device access, binding to low sockets, etc). I wouldn't set something to ro on purpose, but could imagine accidentally changing ownership if (as root) I did a quick edit on a file... Regardless, interesting bug. Fossil doesn't store/set any attributes except +x (git doesn't support other attributes either (anymore), based on what i've read). -- - 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 ___ 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: Failure to acknowledge changes after failing to overwrite write-protected file
And I have to ask: Why do you have to ask? :) A problem is a problem regardless of how it became evident. No, I don’t keep read-only files under fossil control, obviously. Note I used the word ‘happens’ to be read-only. The read-only status was set to temporarily protect this one file from being overwritten along with all other changed files in the repo. So, rather than answer Y/N to whether to overwrite each file individually from the whole lot, I set the read-only flag to the one I didn’t want overwritten, and answered Yes to all... From: Stephan Beal Sent: Thursday, November 13, 2014 5:20 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file On Wed, Nov 12, 2014 at 10:16 PM, to...@acm.org wrote: When opening a repo, if you select to overwrite all files, and a file to be updated happens to be read-only (R attrib set), the overwrite fails (it should) but if you then change the read-only to read-write, and try to see changes or try to revert the failed to update file with the repo version, nothing happens. FOSSIL somehow assumes that the checkout is in a correct state, even though it failed to overwrite, and the repo and check-out have different copies of the same file. That's apparently a bug (and thank you for the reproduction steps), but i've gotta ask: why on earth would have a read-only file under fossil's control (as opposed to having read-only generated files, which i do to keep me from accidentally editing the generated Makefiles instead of their input tempates)? Fossil doesn't store/set any attributes except +x (git doesn't support other attributes either (anymore), based on what i've read). -- - 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 ___ 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: Failure to acknowledge changes after failing to overwrite write-protected file
On Thu, Nov 13, 2014 at 6:11 PM, to...@acm.org wrote: And I have to ask: Why do you have to ask? :) A problem is a problem regardless of how it became evident. Because i'm deciding whether it's worth investing time to fix what might be a non-problem (or a problem outside fossil's scope) ;). FWIW: i generally cringe when people respond to posts with why would you want to? and should have said why i was asking in my initial reply. No, I don’t keep read-only files under fossil control, obviously. Note I used the word ‘happens’ to be read-only. Fair enough. The read-only status was set to temporarily protect this one file from being overwritten along with all other changed files in the repo. So, rather than answer Y/N to whether to overwrite each file individually from the whole lot, I set the read-only flag to the one I didn’t want overwritten, and answered Yes to all... In any case, i agree it's a bug, but looking into it isn't high on my personal prio list because it's a really weird edge case with relatively little impact (as perceived by my limited world view). Could i convince you to post a ticket for it, including the bits from your first post, so we don't lose track of it? -- - 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: Failure to acknowledge changes after failing to overwrite write-protected file
I agree it’s not an everyday use case. I’ve been using fossil for nearly a year now, and it happened to me only once, just now. And, I’ve learned my lesson, so I’ll be more careful for this not to happen again. However, this is the kind of situation that it may not bite often at all but if it ever bites you, it might hurt a lot as you’ll end up losing possibly the only copy of a file, as committing won’t include this one, and closing the repo won’t warn you about uncommitted changes, and you may go home happy thinking everything is in order... until you blissfully overwrite it (this now no longer read-only file) next time you open the repo with the wrong version. From: Stephan Beal Sent: Thursday, November 13, 2014 7:19 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file On Thu, Nov 13, 2014 at 6:11 PM, to...@acm.org wrote: And I have to ask: Why do you have to ask? :) A problem is a problem regardless of how it became evident. Because i'm deciding whether it's worth investing time to fix what might be a non-problem (or a problem outside fossil's scope) ;). FWIW: i generally cringe when people respond to posts with why would you want to? and should have said why i was asking in my initial reply. No, I don’t keep read-only files under fossil control, obviously. Note I used the word ‘happens’ to be read-only. Fair enough. The read-only status was set to temporarily protect this one file from being overwritten along with all other changed files in the repo. So, rather than answer Y/N to whether to overwrite each file individually from the whole lot, I set the read-only flag to the one I didn’t want overwritten, and answered Yes to all... In any case, i agree it's a bug, but looking into it isn't high on my personal prio list because it's a really weird edge case with relatively little impact (as perceived by my limited world view). Could i convince you to post a ticket for it, including the bits from your first post, so we don't lose track of it? -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Error after fossil import from git: Missing changeset
Howdy, Discovered a potential bug with fossil's ability to import git repositories. This issue appears to happen when a git repository has a commit that removes all files from it. What happens is that fossil 'skips' the changeset with all files removed in it, resulting in a dangling ancestor. Note I am attaching a compressed git fast-export stream from a git repository I created to illustrate the bug. How to reproduce using the attached fast-export stream: 1) gunzip -c example.fi.gz | fossil import --git example.fossil 2) fossil ui example.fossil 3) Select 'Timeline' You will see that 'trunk' goes up until it hits the revision before the deletion of all files. Then the revision that adds files back again is created on a parallel unnamed branch with a dangling ancestor. As a side effect of this, if you attempt to open a changeset on the 'dangling' branch and edit it via the UI, you are greeted with the following: fossil(81780,0x7fff7a242310) malloc: *** error for object 0x10db30790: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug This behavior was seen on Fossil 1.28. Note I checked the fast-export stream and the 'delete' commit is there, so something is eating the commit. As a side note, is there any way to recover from this scenario? I've got a personal 16 year old repository that went from CVS - Subversion - Fossil by way of git that has the 'dangling' commit and I'm unable to edit the starting point of the dangling commit due to the pointer error above. If you require any further information or want me to create a ticket, let me know. Cheers! -- Christopher M. Fuhrman cfuhr...@pobox.com example.fi.gz Description: GNU Zip compressed data ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
