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

[Tony Papadimitriou]

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 pretty 
much have to guess what number to use to get enough entries displayed.

To see what I’m talking about try the following with the sqlite3 repo:

fossil tim -p src\shell.c p current

(I think –n defaults to 20.) I get just 1 entry.  Now try:

fossil tim -p src\shell.c p current -n 50

I get just 4 entries.  But with –n 0 (unlimited) I get 885.

This happens with at least v1.36 [65e69b8dd8] and v1.37 [6f3ec1bef6].

Thanks___
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 fossil version 1.35 [9cf0dbe5fb] when using fossil ui

[Alexandru Birsanu]

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
>> 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
>>
>> SQLITE_ERROR: no such column: blob.rid
>> Database Error
>> no such column: blob.rid SELECT EXISTS (SELECT 1 FROM event WHERE
>> mtime<=2457462.838460649 AND (EXISTS(SELECT 1 FROM tagxref WHERE
>> tagid=12 AND tagtype>0 AND rid=blob.rid) OR EXISTS(SELECT 1 FROM plink
>> CROSS JOIN tagxref ON rid=cid WHERE tagid=12 AND tagtype>0 AND
>> pid=blob.rid) AND NOT EXISTS(SELECT 1 FROM plink JOIN tagxref ON rid=cid
>> WHERE tagid=5 AND tagtype>0 AND pid=blob.rid) OR EXISTS(SELECT 1 FROM
>> plink CROSS JOIN tagxref ON rid=pid WHERE tagid=12 AND tagtype>0 AND
>> cid=blob.rid) AND NOT EXISTS(SELECT 1 FROM plink JOIN tagxref ON rid=pid
>> WHERE tagid=5 AND tagtype>0 AND cid=blob.rid) ))
>
>
> I fixed this. Please try now.
>
>
> --
> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
>
> ___
> 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 in fossil version 1.35 [9cf0dbe5fb] when using fossil ui

[Baruch Burstein]

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 ui repo.fossil
> 4. click on timeline > click on the 'trunk' link. you should get an error
>
> SQLITE_ERROR: no such column: blob.rid
> Database Error
> no such column: blob.rid SELECT EXISTS (SELECT 1 FROM event WHERE
> mtime<=2457462.838460649 AND (EXISTS(SELECT 1 FROM tagxref WHERE
> tagid=12 AND tagtype>0 AND rid=blob.rid) OR EXISTS(SELECT 1 FROM plink
> CROSS JOIN tagxref ON rid=cid WHERE tagid=12 AND tagtype>0 AND
> pid=blob.rid) AND NOT EXISTS(SELECT 1 FROM plink JOIN tagxref ON rid=cid
> WHERE tagid=5 AND tagtype>0 AND pid=blob.rid) OR EXISTS(SELECT 1 FROM
> plink CROSS JOIN tagxref ON rid=pid WHERE tagid=12 AND tagtype>0 AND
> cid=blob.rid) AND NOT EXISTS(SELECT 1 FROM plink JOIN tagxref ON rid=pid
> WHERE tagid=5 AND tagtype>0 AND cid=blob.rid) ))


I fixed this. Please try now.


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Alexandru Birsanu]

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

SQLITE_ERROR: no such column: blob.rid
Database Error
no such column: blob.rid SELECT EXISTS (SELECT 1 FROM event WHERE
mtime<=2457462.838460649 AND (EXISTS(SELECT 1 FROM tagxref WHERE
tagid=12 AND tagtype>0 AND rid=blob.rid) OR EXISTS(SELECT 1 FROM plink
CROSS JOIN tagxref ON rid=cid WHERE tagid=12 AND tagtype>0 AND
pid=blob.rid) AND NOT EXISTS(SELECT 1 FROM plink JOIN tagxref ON rid=cid
WHERE tagid=5 AND tagtype>0 AND pid=blob.rid) OR EXISTS(SELECT 1 FROM
plink CROSS JOIN tagxref ON rid=pid WHERE tagid=12 AND tagtype>0 AND
cid=blob.rid) AND NOT EXISTS(SELECT 1 FROM plink JOIN tagxref ON rid=pid
WHERE tagid=5 AND tagtype>0 AND cid=blob.rid) ))

Also, the default text from /home when creating a new repository has
Then create a wiki page with that name.
this should probably be replaced by something like
A wiki page with that name will be automatically created.
___
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 dc72fd9624 whenadding--with-th1-hooks

[Alexandru Birsanu]

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, which I just
noticed was not compiled with the TH1_HOOKS feature.

On Tue, Mar 1, 2016 at 12:55 AM, Ross Berteig  wrote:
>
> 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 repo.fossil
>> fossil server repo.fossil
>
>
> One other note. The chroot jail is strongest when the repo being served
> is not itself owned by root. After calling chroot(), it lowers
> privileges by impersonating the user that owns the repository. If that
> user is root, it still impersonated itself but that has little or no
> effect. So let some normal user own the repositories you serve, and the
> folder they live in.
>
> This implies that the folder containing the repository must be readable
> and writable by the user that owns the repository, if not actually owned
> by that user.
>
> Incidentally, the chroot jail feature has been in fossil for a long
> time. It is first mentioned in a check-in comment from August 2009, and
> the oldest surviving lines of code related to it date from February
> 2010. I don't know why it hasn't affected you before, unless your past
> usage has generally involved running fossil as other than root when
> serving files, which is exactly what would normally happen if fossil
> were accessed via CGI since web servers are usually not running as root.
>
> --
> Ross Berteig   r...@cheshireeng.com
> Cheshire Engineering Corp.   http://www.CheshireEng.com/
> +1 626 303 1602
> ___
> 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 in dc72fd9624 whenadding--with-th1-hooks

[Ross Berteig]

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 repo.fossil
fossil server repo.fossil


One other note. The chroot jail is strongest when the repo being served
is not itself owned by root. After calling chroot(), it lowers
privileges by impersonating the user that owns the repository. If that
user is root, it still impersonated itself but that has little or no
effect. So let some normal user own the repositories you serve, and the
folder they live in.

This implies that the folder containing the repository must be readable
and writable by the user that owns the repository, if not actually owned
by that user.

Incidentally, the chroot jail feature has been in fossil for a long
time. It is first mentioned in a check-in comment from August 2009, and
the oldest surviving lines of code related to it date from February
2010. I don't know why it hasn't affected you before, unless your past
usage has generally involved running fossil as other than root when
serving files, which is exactly what would normally happen if fossil
were accessed via CGI since web servers are usually not running as root.

--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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 dc72fd9624 when adding--with-th1-hooks

[Alexandru Birsanu]

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
>> 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:
>>>
>>>
>>> Alexandru Birsanu wrote:


 ./fossil server repo.fossil
 results in an "invalid home directory: /root" error when using a
 browser to connect.
>
>
> A couple of considerations that leap to mind:
>
> 1. $FOSSIL_HOME and $HOME are read at run time, in that order, and the
> first found is used as the home directory for this invocation. Their
> values at configure and build time would only affect the build tools,
> not the built fossil.
>
> 2. Don't build while logged in as root. That is trusting our Makefile
> and build system too much, not that we can't be trusted. ;-)
>
> 3. As others have said by now, when fossil is running as root, certain
> commands will enter a chroot jail rooted at the folder containing the
> repository and drop all privileges, before reading any bytes from the
> wire and especially before acting on anything it read from the wire.
> This is for your protection.
>
> 4. That chroot jail must contain certain folder and resources. Namely,
> anything required for fossil to run, such as the folder named by
> $FOSSIL_HOME or $HOME, /dev/null, /dev/urandom, and if you want your
> server to be able to display timeline dates in your local time zone also
> include /etc/localtime.
>
> 5. The error you have says that it knew that the home directory was
> /root, but that directory did not exist inside the chroot jail. Fossil
> requires a home directory to point somewhere it can read and write.
>
> 6. Working with a non-root user is expected as long as $FOSSIL_HOME or
> $HOME are pointing at a directory writable by that user, as it won't
> enter a jail and so the whole file system is available.
>
>>> 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
>>> with TH1 hooks enabled?
>>>
>>> --
>>> Joe Mistachkin
>
>
> --
> Ross Berteig   r...@cheshireeng.com
> Cheshire Engineering Corp.   http://www.CheshireEng.com/
> +1 626 303 1602
> ___
> 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 in dc72fd9624 whenadding--with-th1-hooks

[Alexandru Birsanu]

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, 2016 at 7:36 PM, 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
>>> --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 jail.  You'll need
>> to take that into consideration when setting the FOSSIL_HOME variable.
>>
>
> 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 jail on the directory holding the
> repository then drop all root privileges - before reading the first
> byte off of the wire.
>
> --
> 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] possible bug in dc72fd9624 whenadding--with-th1-hooks

[Richard Hipp]

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
___
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 dc72fd9624 whenadding--with-th1-hooks

[Ross Berteig]

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 jail on the directory holding the
repository then drop all root privileges - before reading the first
byte off of the wire.


Could you point to where in the code the chroot is created?


The jail is implemented by enter_chroot_jail() in main.c ca. line 1463:


https://www.fossil-scm.org/index.html/artifact/e75796be5338a81c?ln=1463,1523

That function is called in "fossil http", "fossil server", and "fossil 
ui", also implemented in main.c.



--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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 dc72fd9624 whenadding--with-th1-hooks

[jungle Boogie]

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
>>> --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 jail.  You'll need
>> to take that into consideration when setting the FOSSIL_HOME variable.
>>
>
> 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 jail on the directory holding the
> repository then drop all root privileges - before reading the first
> byte off of the wire.
>

Could you point to where in the code the chroot is created?

> --
> D. Richard Hipp
> d...@sqlite.org


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
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 dc72fd9624 when adding--with-th1-hooks

[Ross Berteig]

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 Mistachkin  wrote:


Alexandru Birsanu wrote:


./fossil server repo.fossil
results in an "invalid home directory: /root" error when using a
browser to connect.


A couple of considerations that leap to mind:

1. $FOSSIL_HOME and $HOME are read at run time, in that order, and the
first found is used as the home directory for this invocation. Their
values at configure and build time would only affect the build tools,
not the built fossil.

2. Don't build while logged in as root. That is trusting our Makefile
and build system too much, not that we can't be trusted. ;-)

3. As others have said by now, when fossil is running as root, certain
commands will enter a chroot jail rooted at the folder containing the
repository and drop all privileges, before reading any bytes from the
wire and especially before acting on anything it read from the wire.
This is for your protection.

4. That chroot jail must contain certain folder and resources. Namely,
anything required for fossil to run, such as the folder named by
$FOSSIL_HOME or $HOME, /dev/null, /dev/urandom, and if you want your
server to be able to display timeline dates in your local time zone also
include /etc/localtime.

5. The error you have says that it knew that the home directory was
/root, but that directory did not exist inside the chroot jail. Fossil
requires a home directory to point somewhere it can read and write.

6. Working with a non-root user is expected as long as $FOSSIL_HOME or
$HOME are pointing at a directory writable by that user, as it won't
enter a jail and so the whole file system is available.


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
with TH1 hooks enabled?

--
Joe Mistachkin


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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 dc72fd9624 whenadding--with-th1-hooks

[Richard Hipp]

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
>> works fine.
>>
>
> IIRC, the "fossil server" command runs in a chroot jail.  You'll need
> to take that into consideration when setting the FOSSIL_HOME variable.
>

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 jail on the directory holding the
repository then drop all root privileges - before reading the first
byte off of the wire.

-- 
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 dc72fd9624 whenadding--with-th1-hooks

[Joe Mistachkin]

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 jail.  You'll need
to take that into consideration when setting the FOSSIL_HOME variable.

--
Joe Mistachkin

___
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 dc72fd9624 when adding--with-th1-hooks

[Alexandru Birsanu]

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:
>
> 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
> with TH1 hooks enabled?
>
> --
> Joe Mistachkin
>
> ___
> 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 in dc72fd9624 when adding--with-th1-hooks

[Joe Mistachkin]

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
with TH1 hooks enabled?

--
Joe Mistachkin

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Alexandru Birsanu]

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 --with-th1-docs --with-tcl --with-tcl-stubs
--with-tcl-private-stubs
works fine. I've tried it on CentOS 7.1 and Fedora 23 and Ubuntu 15.10.
Thanks for the amazing program by the way.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Alexey V Gorshkov]

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 commands, repository is locked and can not be committed into.

[possible bug] pull from empty repo to empty 'open' dir deadlocks repo
___
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] pull from empty repo to empty 'open' dir deadlocks repo

[Alexey V Gorshkov]

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


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 commands, repository is locked and can not be committed into.

[possible bug] pull from empty repo to empty 'open' dir deadlocks repo
___
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] pull from empty repo to empty 'open' dir deadlocks repo

[Alexey V Gorshkov]

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 open ../test.fossil; fossil pull
../test.fossil, you are trying to pull from the repository itself,
which is naturally a dead lock. Why do you expect that to work (or even
provide something useful)?

Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
I'm first time fossil user and simply wanted to learn stuff frough 
experiments

___
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] pull from empty repo to empty 'open' dir deadlocks repo

[Joerg Sonnenberger]

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
../test.fossil, you are trying to pull from the repository itself,
which is naturally a dead lock. Why do you expect that to work (or even
provide something useful)?

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] Possible bug with [G]DIFF

[Andy Bradford]

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? What OS? Was Fossil built  from source? If yes,
did ``make clean'' get done first?

Thanks,

Andy
-- 
TAI64 timestamp: 4000559c937f


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Tony Papadimitriou]

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 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

[Scott Robison]

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] Possible Bug in Merge Conflict Blocks

[bch]

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

[fossil-users] Possible Bug in Merge Conflict Blocks

[Scott Robison]

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.

I view src\file.c where there is a single merge conflict. The first block
(BEGIN MERGE CONFLICT: local copy shown first) shows exactly what I'd
expect to see. The second and third blocks, however, are missing the last
line from each. In this case the last line should be #endif for both the
COMMON ANCESTER  MERGED IN blocks. Instead it is showing the all except
for the final line.

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.

-- 
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] Possible Bug in Merge Conflict Blocks

[Richard Hipp]

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
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

[bch]

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 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.


 Understood. I'll see what I can find.

 --
 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] Possible Bug in Merge Conflict Blocks

[Scott Robison]

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 right now.  Please have a look and send patches.
 Tnx.


Understood. I'll see what I can find.

-- 
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] Possible Bug in Merge Conflict Blocks

[bch]

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.

-bch


On 3/18/15, Scott Robison sc...@casaderobison.com wrote:
 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 directory of fossil, run fossil update 44a160a341
 (the most recent winsymlink branch prior to one I updated earlier today).

 2. Next, fossil merge a7e1101d71 (merge the last almost five months of
 trunk updates).

 3. Observe that there are merge conflicts for src/file.c, src/update.c, and
 src/vfile.c.

 4. Open src/file.c and go to BEGIN MERGE CONFLICT at line 295.

 4a. The local copy shown first portion is fine. It shows exactly the body
 of the file_wd_perm function from the original version of the file. Diff
 src/file.c against src/file.c-original and you should see it immediately
 (or at least I did with WinMerge).

 4b. The COMMON ANCESTOR portion is missing #endif  from line 259 of the
 baseline version of the file. Diff src/file.c against src/file.c-baseline
 to see the missing line.

 4c. The MERGED IN portion is missing #endif from line 249 of the merge
 version of the file. Diff src/file.c against src/file.c-merge to see the
 missing line.

 So if you discard the COMMON ANCESTOR and MERGED IN versions, you'll have a
 a complete body. If you discard the local copy and keep one of COMMON
 ANCESTOR or MERGED IN, you'll have an incomplete body. If you look at it
 for an hour or so trying to make sense of which if any pieces of each
 version you should include, you'll be quite confused as you try to come to
 terms with your first merge conflict and simultaneous uncertainty about the
 meanings COMMON ANCESTOR / baseline and MERGED IN / merge and local
 copy / original and where to find all this in src/file.c. Or at least I
 was. It was a perfect storm. Confusing changes between trunk  branch 
 some sleep deprivation experiment my body is forcing me into took me a
 while to come to the realization I shared above.

 --
 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] Possible Bug in Merge Conflict Blocks

[Scott Robison]

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.


Understood. It is arguable in my mind that either the #endif should be in
both of the baseline and merge portions, or that it should be present once
after the merge conflict block. To not show it anywhere around the merge
conflict though seems wrong. I'm also looking / debugging, trying to puzzle
it out. I've created another repository that just has that one function
from that one file in a similar trunk/branch configuration, and the same
behavior is still present. Will keep looking.
-- 
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] Possible Bug in Merge Conflict Blocks

[Scott Robison]

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 directory of fossil, run fossil update 44a160a341
(the most recent winsymlink branch prior to one I updated earlier today).

2. Next, fossil merge a7e1101d71 (merge the last almost five months of
trunk updates).

3. Observe that there are merge conflicts for src/file.c, src/update.c, and
src/vfile.c.

4. Open src/file.c and go to BEGIN MERGE CONFLICT at line 295.

4a. The local copy shown first portion is fine. It shows exactly the body
of the file_wd_perm function from the original version of the file. Diff
src/file.c against src/file.c-original and you should see it immediately
(or at least I did with WinMerge).

4b. The COMMON ANCESTOR portion is missing #endif  from line 259 of the
baseline version of the file. Diff src/file.c against src/file.c-baseline
to see the missing line.

4c. The MERGED IN portion is missing #endif from line 249 of the merge
version of the file. Diff src/file.c against src/file.c-merge to see the
missing line.

So if you discard the COMMON ANCESTOR and MERGED IN versions, you'll have a
a complete body. If you discard the local copy and keep one of COMMON
ANCESTOR or MERGED IN, you'll have an incomplete body. If you look at it
for an hour or so trying to make sense of which if any pieces of each
version you should include, you'll be quite confused as you try to come to
terms with your first merge conflict and simultaneous uncertainty about the
meanings COMMON ANCESTOR / baseline and MERGED IN / merge and local
copy / original and where to find all this in src/file.c. Or at least I
was. It was a perfect storm. Confusing changes between trunk  branch 
some sleep deprivation experiment my body is forcing me into took me a
while to come to the realization I shared above.

-- 
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] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

[Stephan Beal]

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

[B Harder]

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

[tonyp]

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

[Stephan Beal]

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

[tonyp]

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] Possible bug: Failure to acknowledge changes after failing to overwrite write-protected file

[tonyp]

(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 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.

Here’s the test batch file I ran which shows the problem:

@echo off
echo Reproduce fossil issue with read-only overwrite failure consequences
echo (where f = fossil)
f ver -v
f new sample.fossil
md xxx
dir  xxx\aaa
cd xxx
f o ..\sample.fossil
f add aaa
f com -m Initial
f close
echo Make some changes to our file
dir ../s  aaa
attrib +r aaa
echo Answer Y or A(ll)
f o ..\sample.fossil
echo Failed to update.  Let's remove the read-only status, and see...
attrib -r aaa
f cha
f rev
f com
echo Nothing shown here.  But, if we close and re-open the repo.
f close
echo Answer N
f o ..\sample.fossil
f cha
echo Obviously, there are changes!!!


--
OUTPUT
--
Reproduce fossil issue with read-only overwrite failure consequences
(where f = fossil)
This is fossil version 1.30 [b9a1beda9e] 2014-10-25 01:01:31 UTC
Compiled on Oct 25 2014 19:30:07 using msc-18.00 (32-bit)
SQLite 3.8.7 2014-10-17 11:24:17 e4ab094f8a
Schema version 2011-04-25 19:50
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.1j 15 Oct 2014)
project-id: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7
server-id:  2f3a9fff39ebc03e8d9879929afa6075b8ee766f
admin-user: Tony (initial password is db3f67)
project-name: unnamed
repository:   C:/temp/xxx/..\sample.fossil
local-root:   C:/temp/xxx/
config-db:C:/Users/Tony/AppData/Local/_fossil
project-code: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7
checkins: 0
ADDED  aaa
New_Version: e2507b54298d9a57da83578667dc510861fed766
Make some changes to our file
Answer Y or A(ll)
overwrite C:/temp/xxx/aaa (a=always/y/N)? y
aaa
unable to open file C:/temp/xxx/aaa for writing
Failed to update.  Let's remove the read-only status, and see...
nothing has changed; use --allow-empty to override
Nothing shown here.  But, if we close and re-open the repo.
Answer N
overwrite C:/temp/xxx/aaa (a=always/y/N)?
WARNING: manifest checksum does not agree with disk
project-name: unnamed
repository:   C:/temp/xxx/..\sample.fossil
local-root:   C:/temp/xxx/
config-db:C:/Users/Tony/AppData/Local/_fossil
project-code: 097d5ac10db92bfe4d77daf15c6f2d34b75aaef7
checkout: e2507b54298d9a57da83578667dc510861fed766 2014-11-12 21:12:17 UTC
leaf: open
tags: trunk
comment:  Initial (user: Tony)
checkins: 1
EDITED aaa
Obviously, there are changes!!!
___
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

[Kees Nuyt]

[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 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.

What are your settings for mtime-changes and repo-cksum ?

-- 
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] Possible bug: Failure to acknowledge changesafter failing to overwrite write-protected file

[tonyp]

From the F SET command I see blanks for either:


mtime-changes
...
repo-cksum

Regarding mtime, I understand the batch file test maybe too fast for the 
time to change, but the problem was noticed on a file that was many hours 
away from the repo version.


-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 
changesafter 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 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.


What are your settings for mtime-changes and repo-cksum ?

--
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 


___
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 changesafter failing to overwrite write-protected file

[Kees Nuyt]

On Wed, 12 Nov 2014 23:42:15 +0200, to...@acm.org wrote:

 From the F SET command I see blanks for either:

 mtime-changes
...
 repo-cksum

Hm, ok, so both are default, which is on.

 Regarding mtime, I understand the batch file test maybe too fast for the 
 time to change, but the problem 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 
changesafter 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 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.

What are your settings for mtime-changes and repo-cksum ?
___
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.

[Joan Picanyol i Puig]

* 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 a bug 
 or intended behavior.

Known issue.

http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04760.html
http://fossil-scm.org/index.html/tktview?name=ee97701f4c

I currently use the trick of symlinking / from a working directory, it
works for me. I'm unsure how it interacts with the symlink-related
settings.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Possible bug.

[John Found]

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 
http://asm32.hopto.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.

[Stephan Beal]

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 bug, but suspect it is an
unfortunate edge case.

(sent from a mobile device - please excuse brevity, typos, and top-posting)
- stephan beal
http://wanderinghorse.net
On Feb 26, 2013 9:16 PM, John Found johnfo...@evrocom.net wrote:

 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
 http://asm32.hopto.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] Possible bug.

[Michael L. Barrow]

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 cannot say whether the not-found-from-/ is a bug, but suspect it is 
an unfortunate edge case.





What that person wants is etckepeer, except for the small and annoying 
fact that it doesn't support fossil out of the box. I haven't yet been 
motivated enough to see what it would take to graft fossil support onto 
it however because I'm not currently looking for any(more) 
procrastination targets. :-)


--
michael at barrow dot me
+1.408.782.4249

___
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 timeline?

[Eduardo Morrás]

- 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]:
 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 stays at 20.
[snips]
  
  Can anyone else confirm?  If so, I'll submit a bug.
 
 Same thing here...

Thanks!  Submitted: http://www.fossil-scm.org/index.html/tktview?name=9de46d5bf4

Regards,
-- 
dave [ please don't CC me ]



It's not a bug, there's only 21 timeline items since day 15. It's a coincidence.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Possible bug in timeline?

[David J. Weller-Fahy]

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
4. Click 200 Entries

Note, the number of entries stays at 20.

I tried this on the URL above, and a self-hosted repository.

Can anyone else confirm?  If so, I'll submit a bug.

Regards,
-- 
dave [ please don't CC me ]


pgpPTLIHX9aws.pgp
Description: PGP 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] Possible bug in timeline?

[Martin Gagnon]

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 behavior (described below).
 
 Steps to reproduce:
 
 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 stays at 20.
 
 I tried this on the URL above, and a self-hosted repository.
 
 Can anyone else confirm?  If so, I'll submit a bug.
 
 Regards,
 -- 
 dave [ please don't CC me ]
 ___
 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 in timeline?

[David J. Weller-Fahy]

* 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 stays at 20.
[snips]
  
  Can anyone else confirm?  If so, I'll submit a bug.
 
 Same thing here...

Thanks!  Submitted: http://www.fossil-scm.org/index.html/tktview?name=9de46d5bf4

Regards,
-- 
dave [ please don't CC me ]


pgpwjz7Y4MaoJ.pgp
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Stephan Beal]

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 called twice for the timeline, which
seems unnecessary (whereas the second db_open_repository() is a no-op).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users