[fossil-users] Possible bug with the TIMELINE under some conditions

I noticed that when a filter is applied to the timeline (such as ‘parent current’), AND the –p option is used to filter for a specific file, then the –n option (implicit or explicit) seems to count entries towards the limit regardless of whether these are displayed or not. The result is you

Re: [fossil-users] possible bug in fossil version 1.35 [9cf0dbe5fb] when using fossil ui

It works fine now. Thanks for the quick response. On Tue, Mar 15, 2016 at 11:22 AM, Baruch Burstein wrote: > On Tue, Mar 15, 2016 at 10:27 AM, Alexandru Birsanu > wrote: >> >> Hi, I think I've found a bug in fossil 9cf0dbe5fb. This bug is not

Re: [fossil-users] possible bug in fossil version 1.35 [9cf0dbe5fb] when using fossil ui

On Tue, Mar 15, 2016 at 10:27 AM, Alexandru Birsanu < alexandru.birs...@gmail.com> wrote: > Hi, I think I've found a bug in fossil 9cf0dbe5fb. This bug is not > present in fossil 1.34. To replicate: > 1. build fossil by double clicking on win\buildmsvc.bat > 2. fossil new repo.fossil > 3. fossil

[fossil-users] possible bug in fossil version 1.35 [9cf0dbe5fb] when using fossil ui

Hi, I think I've found a bug in fossil 9cf0dbe5fb. This bug is not present in fossil 1.34. To replicate: 1. build fossil by double clicking on win\buildmsvc.bat 2. fossil new repo.fossil 3. fossil ui repo.fossil 4. click on timeline > click on the 'trunk' link. you should get an error

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

Thanks, I'll create a new account for the repositories from now on and set FOSSIL_HOME=/. The problem only appears if I run fossil as root when compiled with --with-th1-hooks as one of the options and FOSSIL_HOME is not set. Before this, I used the "Linux 3.x x86" version from fossil-scm.org,

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

On 2/29/2016 3:01 PM, Alexandru Birsanu wrote: Thanks for the explanations. Since Fossil 1.34 didn't have this issue I assumed it might be a bug not a new feature :). I've tried the following and it works great when run as root. export FOSSIL_HOME=/ mkdir /repos && cd /repos fossil new

Re: [fossil-users] possible bug in dc72fd9624 when adding--with-th1-hooks

Thanks for the very clear explanation. I'll try to build as non-root from now on ;-). On Mon, Feb 29, 2016 at 8:19 PM, Ross Berteig wrote: > > On 2/29/2016 2:28 AM, Alexandru Birsanu wrote: >> >> HOME=/root and FOSSIL_HOME is not set. It still doesn't work if I set >>

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

Thanks for the explanations. Since Fossil 1.34 didn't have this issue I assumed it might be a bug not a new feature :). I've tried the following and it works great when run as root. export FOSSIL_HOME=/ mkdir /repos && cd /repos fossil new repo.fossil fossil server repo.fossil On Mon, Feb 29,

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

On 2/29/16, jungle Boogie wrote: > > Could you point to where in the code the chroot is created? https://en.wikipedia.org/wiki/Grep https://www.fossil-scm.org/fossil/artifact/e75796be533?ln=1462-1523 -- D. Richard Hipp d...@sqlite.org

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

On 2/29/2016 11:43 AM, jungle Boogie wrote: On 29 February 2016 at 10:36, Richard Hipp wrote: Right. The "fossil server", "fossil http", "fossil cgi" and similar commands all check to see if they are running as root, and if they are they immediately create a chroot

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

On 29 February 2016 at 10:36, Richard Hipp wrote: > On 2/29/16, Joe Mistachkin wrote: >> >> Alexandru Birsanu wrote: >>> >>> HOME=/root and FOSSIL_HOME is not set. It still doesn't work if I set >>> FOSSIL_ROOT to /root before make clean && ./configure >>>

Re: [fossil-users] possible bug in dc72fd9624 when adding--with-th1-hooks

On 2/29/2016 2:28 AM, Alexandru Birsanu wrote: HOME=/root and FOSSIL_HOME is not set. It still doesn't work if I set FOSSIL_ROOT to /root before make clean && ./configure --with-th1-hooks. I've also tested it with a non-root user, and that works fine. On Sun, Feb 28, 2016 at 10:46 PM, Joe

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

On 2/29/16, Joe Mistachkin wrote: > > Alexandru Birsanu wrote: >> >> HOME=/root and FOSSIL_HOME is not set. It still doesn't work if I set >> FOSSIL_ROOT to /root before make clean && ./configure >> --with-th1-hooks. I've also tested it with a non-root user, and that >>

Re: [fossil-users] possible bug in dc72fd9624 whenadding--with-th1-hooks

Alexandru Birsanu wrote: > > HOME=/root and FOSSIL_HOME is not set. It still doesn't work if I set > FOSSIL_ROOT to /root before make clean && ./configure > --with-th1-hooks. I've also tested it with a non-root user, and that > works fine. > IIRC, the "fossil server" command runs in a chroot

Re: [fossil-users] possible bug in dc72fd9624 when adding--with-th1-hooks

HOME=/root and FOSSIL_HOME is not set. It still doesn't work if I set FOSSIL_ROOT to /root before make clean && ./configure --with-th1-hooks. I've also tested it with a non-root user, and that works fine. On Sun, Feb 28, 2016 at 10:46 PM, Joe Mistachkin wrote: > >

Re: [fossil-users] possible bug in dc72fd9624 when adding--with-th1-hooks

Alexandru Birsanu wrote: > > ./fossil server repo.fossil > results in an "invalid home directory: /root" error when using a > browser to connect. > What are your FOSSIL_HOME and HOME environment variables set to? Can you try setting FOSSIL_HOME to the right home directory prior to running

[fossil-users] possible bug in dc72fd9624 when adding --with-th1-hooks

Hi, I think I've found a possible bug in "fossil version 1.35 [dc72fd9624] 2016-02-27 02:12:31 UTC". When adding --with-th1-hooks to ./configure, ./fossil server repo.fossil results in an "invalid home directory: /root" error when using a browser to connect. Also, ./configure --json

[fossil-users] [possible bug] pull from empty repo to empty 'open' dir deadlocks repo

fossil in question: This is fossil version 1.33 [9c65b5432e] 2015-05-23 11:11:31 UTC following sequence of commands locks newly created repository -- mkdir fos cd fos fossil init test.fossil mkdir t cd t fossil open ../test.fossil fossil pull ../test.fossil -- after this

Re: [fossil-users] [possible bug] pull from empty repo to empty 'open' dir deadlocks repo

sorry, missformatted command sequence text mkdir fos cd fos fossil init test.fossil mkdir t cd t fossil open ../test.fossil fossil pull ../test.fossil On 07/19/2015 10:42 AM, Alexey V Gorshkov wrote: fossil in question: This is fossil version 1.33 [9c65b5432e] 2015-05-23 11:11:31 UTC

Re: [fossil-users] [possible bug] pull from empty repo to empty 'open' dir deadlocks repo

On 07/19/2015 05:51 PM, Joerg Sonnenberger wrote: On Sun, Jul 19, 2015 at 10:45:29AM +0300, Alexey V Gorshkov wrote: sorry, missformatted command sequence text mkdir fos cd fos fossil init test.fossil mkdir t cd t fossil open ../test.fossil fossil pull ../test.fossil Assuming this is fossil

Re: [fossil-users] [possible bug] pull from empty repo to empty 'open' dir deadlocks repo

On Sun, Jul 19, 2015 at 10:45:29AM +0300, Alexey V Gorshkov wrote: sorry, missformatted command sequence text mkdir fos cd fos fossil init test.fossil mkdir t cd t fossil open ../test.fossil fossil pull ../test.fossil Assuming this is fossil open ../test.fossil; fossil pull

Re: [fossil-users] Possible bug with [G]DIFF

Thus said Tony Papadimitriou on Tue, 07 Jul 2015 16:54:30 +0300: f gdiff --from 2015-07-07 where the 2015-07-07 date is today, or any date later than the latest check-in, I get a list that looks like the execution of a CHANGES command, which is is certainly incorrect. What version of

[fossil-users] Possible bug with [G]DIFF

When doing: f gdiff --from 2015-07-07 where the 2015-07-07 date is today, or any date later than the latest check-in, I get a list that looks like the execution of a CHANGES command, which is is certainly incorrect. Thanks.___ fossil-users mailing

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

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

[fossil-users] Possible Bug in Merge Conflict Blocks

I was going to get my old winsymlink branch caught up with trunk, so, using a build from the tip of trunk (This is fossil version 1.32 [a7e1101d71] 2015-03-17 21:10:44 UTC) I: 1. fossil update winsymlink 2. fossil merge trunk 3. merge conflict reported for src\file.c, src\update.c, src\vfile.c.

Re: [fossil-users] Possible Bug in Merge Conflict Blocks

On 3/18/15, Scott Robison sc...@casaderobison.com wrote: Just FYI. I can try to take a look at it later, but given the speed that these things are often fixed, I figured I'd report it now. Too many balls in flight right now. Please have a look and send patches. Tnx. -- D. Richard Hipp

Re: [fossil-users] Possible Bug in Merge Conflict Blocks

Scott -- if there's a case you concoct (and post) that demonstrates the issue, more eyeballs and brains can review. -bch On 3/18/15, Scott Robison sc...@casaderobison.com wrote: On Wed, Mar 18, 2015 at 11:42 AM, Richard Hipp d...@sqlite.org wrote: On 3/18/15, Scott Robison

Re: [fossil-users] Possible Bug in Merge Conflict Blocks

On Wed, Mar 18, 2015 at 11:42 AM, Richard Hipp d...@sqlite.org wrote: On 3/18/15, Scott Robison sc...@casaderobison.com wrote: Just FYI. I can try to take a look at it later, but given the speed that these things are often fixed, I figured I'd report it now. Too many balls in flight

Re: [fossil-users] Possible Bug in Merge Conflict Blocks

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

Re: [fossil-users] Possible Bug in Merge Conflict Blocks

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

Re: [fossil-users] Possible Bug in Merge Conflict Blocks

On Wed, Mar 18, 2015 at 12:19 PM, bch brad.har...@gmail.com wrote: Scott -- if there's a case you concoct (and post) that demonstrates the issue, more eyeballs and brains can review. I posted a Reader's Digest condensed one earlier, but here it is in more detail: 1. From an opened working

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

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

Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

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

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)

Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

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

[fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

(This was seen on a Windows 7 machine) 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

Re: [fossil-users] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

[Default] On Wed, 12 Nov 2014 23:16:34 +0200, to...@acm.org wrote: (This was seen on a Windows 7 machine) 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

Re: [fossil-users] Possible bug: Failure to acknowledge changesafter failing to overwrite write-protected file

Nuyt Sent: Wednesday, November 12, 2014 11:35 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Possible bug: Failure to acknowledge changesafter failing to overwrite write-protected file [Default] On Wed, 12 Nov 2014 23:16:34 +0200, to...@acm.org wrote: (This was seen

Re: [fossil-users] Possible bug: Failure to acknowledge changesafter failing to overwrite write-protected file

was noticed on a file that was many hours away from the repo version. Sorry, I don't have a clue :/ -Original Message- From: Kees Nuyt Sent: Wednesday, November 12, 2014 11:35 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Possible bug: Failure to acknowledge

Re: [fossil-users] Possible bug.

* John Found johnfo...@evrocom.net [20130226 21:14]: This question on stackoverflow maybe needs some attention: http://stackoverflow.com/questions/13787801/how-to-do-fossil-commands-on-relative-directory/14642028#14642028 My experiments indicates some problems, but for me is not clear is it

[fossil-users] Possible bug.

This question on stackoverflow maybe needs some attention: http://stackoverflow.com/questions/13787801/how-to-do-fossil-commands-on-relative-directory/14642028#14642028 My experiments indicates some problems, but for me is not clear is it a bug or intended behavior. -- John Found

Re: [fossil-users] Possible bug.

Brief comment from tablet (and no stackoverflow account) - managing /etc with fossil is a poor idea because it does not support permissions and some files in /etc are very sensitive to ownership and perms. Fossil is not the right tool for that job. i cannot say whether the not-found-from-/ is a

Re: [fossil-users] Possible bug.

On 2/26/13 1:12 PM, Stephan Beal wrote: Brief comment from tablet (and no stackoverflow account) - managing /etc with fossil is a poor idea because it does not support permissions and some files in /etc are very sensitive to ownership and perms. Fossil is not the right tool for that job. i

Re: [fossil-users] Possible bug in timeline?

- Mensaje original - De: David J. Weller-Fahy dave-lists-fossil-us...@weller-fahy.com Para: fossil-users@lists.fossil-scm.org CC: Enviado: Martes 18 de diciembre de 2012 3:39 Asunto: Re: [fossil-users] Possible bug in timeline? * Martin Gagnon eme...@gmail.com [2012-12-17 20:59 -0500

[fossil-users] Possible bug in timeline?

I believe I may have found a bug in the behavior of the timeline. As this may be just me, I figured I'd check with the community to see if anyone else is seeing this behavior (described below). Steps to reproduce: 1. Go to http://www.fossil-scm.org/fossil/timeline 2. Click Older 3. Click Newer

Re: [fossil-users] Possible bug in timeline?

Same thing here... -- Martin Le 2012-12-17 à 20:34, David J. Weller-Fahy dave-lists-fossil-us...@weller-fahy.com a écrit : I believe I may have found a bug in the behavior of the timeline. As this may be just me, I figured I'd check with the community to see if anyone else is seeing this

Re: [fossil-users] Possible bug in timeline?

* Martin Gagnon eme...@gmail.com [2012-12-17 20:59 -0500]: Le 2012-12-17 à 20:34, David J. Weller-Fahy dave-lists-fossil-us...@weller-fahy.com a écrit : 1. Go to http://www.fossil-scm.org/fossil/timeline 2. Click Older 3. Click Newer 4. Click 200 Entries Note, the number of entries

[fossil-users] possible bug + performance hit in timeline_cmd()

Hiya, core dev(s), In timeline_cmd(), is there a reason that: db_find_and_open_repository(0, 0); showfilesFlag = find_option(showfiles,f, 0)!=0; db_find_and_open_repository(0, 0); db_find_and_open_repository() is called twice, or is that a mistake? That can cause db_verify_schema() to be