Re: [fossil-users] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-27 Thread Jan Nijtmans
2014-07-27 23:45 GMT+02:00 Michai Ramakers:
> and thanks for this fix as well - original test works fine here, now.

Merged to trunk now. Thanks for your feedback!

> I'll continue running this branch here until it's merged (although I
> don't make new repos too often). And I'd be interested to do more
> testing if pointed in a direction - although I guess that's difficult
> to do (the pointing).

Don't know, I'm out of ideas for possible more corner-cases.

Regards,
   Jan Nijtmans
___
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] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-27 Thread Michai Ramakers
On 27 July 2014 22:58, Jan Nijtmans  wrote:
> 2014-07-22 11:35 GMT+02:00 Michai Ramakers :
>> Hello,
>>
>> while toying around with Andy Bradford's fix/analysis, found something
>> else, which seems related to the no-initial-commit feature which is
>> recent default in trunk.
>
> This indeed looks like a newly-found corner-case which
> doesn't behave as intuitively expected. Proposed fix here:
>
> 
>
> (I'm not sure yet it's completely covered with this, I'll
> do some more testing...)

and thanks for this fix as well - original test works fine here, now.
I'll continue running this branch here until it's merged (although I
don't make new repos too often). And I'd be interested to do more
testing if pointed in a direction - although I guess that's difficult
to do (the pointing).

Michai
___
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] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-27 Thread Jan Nijtmans
2014-07-22 11:35 GMT+02:00 Michai Ramakers :
> Hello,
>
> while toying around with Andy Bradford's fix/analysis, found something
> else, which seems related to the no-initial-commit feature which is
> recent default in trunk.

This indeed looks like a newly-found corner-case which
doesn't behave as intuitively expected. Proposed fix here:



(I'm not sure yet it's completely covered with this, I'll
do some more testing...)

Thanks!

Regards,
Jan Nijtmans
___
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] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-22 Thread Stephan Beal
On Tue, Jul 22, 2014 at 12:50 PM, Michai Ramakers 
wrote:

> there, it became default again:
>
> http://fossil-scm.org/index.html/info/8364065c45ec839d01e0a0535ebd754f81e9cac4


Ah, i missed that.


> >> 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk)
> >> +++ no more data (2) +++
> >
> > (That last line is a little confusing, IMO. Almost looks like an error.)
>
> the '00:00:00'? That's because of the 'fossil new --date-override
> 2014-01-01' (e.g. fake initial commit well in the past).
>

Doh - didn't even notice that. i meant the "no more data (2)". After
reading it 3 times i understand what it means, but it's not obvious. i have
never noticed it because i've been using f-timeline (from libfossil) since
last summer ;).

-- 
- 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] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-22 Thread Michai Ramakers
On 22 July 2014 11:48, Stephan Beal  wrote:
> On Tue, Jul 22, 2014 at 11:35 AM, Michai Ramakers 
> wrote:
>>
>> (FWIW, I know there have been flaws in this area before, and although
>> I am not a dev having/willing to deal with them, I agree with Jan that
>
> AFAIR i reverted that to not be the default behaviour (IMO it should not be
> because it's a long-standing historical behaviour and we don't fully know
> the implications of removing it).

right, I remember, but I think for the purpose of weeding out bugs
there, it became default again:
http://fossil-scm.org/index.html/info/8364065c45ec839d01e0a0535ebd754f81e9cac4

>> ... "fossil undo" is available to undo changes to the working checkout.
>> /tmp/f/a$ f tim
>> === 2014-07-22 ===
>> 09:22:41 [4b720ef551] *CURRENT* test (user: michai tags: trunk)
>> === 2014-01-01 ===
>> 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk)
>> +++ no more data (2) +++
>
> (That last line is a little confusing, IMO. Almost looks like an error.)

the '00:00:00'? That's because of the 'fossil new --date-override
2014-01-01' (e.g. fake initial commit well in the past).

Michai
___
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] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-22 Thread Stephan Beal
On Tue, Jul 22, 2014 at 11:37 AM, Michai Ramakers 
wrote:

> of course, forgot something:
>
> This is fossil version 1.30 [619fa857c9] 2014-07-19 19:20:25 UTC
>
> (i.e. trunk of this moment)
>

Good man :).

FWIW, as a note to those who generally like to use "officially released
versions" - the majority of us work directly from trunk (or our various
branches) all of the time, and AFAIK none of us have ever lost any data nor
otherwise seriously broken anything. If you have the option of working from
the trunk, IMO that's a better idea that waiting on "official releases," as
we tend to only do those once the feature/bugfix list has grown to some
appreciable length.

-- 
- 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] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-22 Thread Stephan Beal
On Tue, Jul 22, 2014 at 11:35 AM, Michai Ramakers 
wrote:

> (FWIW, I know there have been flaws in this area before, and although
> I am not a dev having/willing to deal with them, I agree with Jan that
>

AFAIR i reverted that to not be the default behaviour (IMO it should not be
because it's a long-standing historical behaviour and we don't fully know
the implications of removing it).


> results in a cleaner design. I don't know how well initial-commit-less
> repos work with older fossil-versions, but I assume that has been
> discussed or considered in detail elsewhere. )
>

LOL! Late last year Jan and i discussed it a bit (not at length) after i
started experimenting with it in libfossil and was curious if fossil could
support it. Jan was the only one brave/gutsy enough to try it out! i knew
from having ported over so many algos from fossil that there were numerous
corner cases, assumptions, and assertions that expected the initial RID to
be in place, but those were just "historical coding decisions" - nothing in
the architecture specifically (or implicitly) prohibits an empty repo. The
bugs we've seen since introducing empty repos have been patching up former
assumptions which are not true in the empty-repo case.


> ---( without initial commit: )---
>
> ...

/tmp/f/a$ f up
> /tmp/f/a$ f tim
> === 2014-07-22 ===
> 09:20:06 [c3450bfdff] test (user: michai tags: trunk)
> +++ no more data (1) +++
> /tmp/f/a$ ls
> /tmp/f/a$
>
> ---( with forced initial commit: )---
>
> Tue Jul 22 11:22:04 CEST 2014
>

Same time zone :)


> ...

... "fossil undo" is available to undo changes to the working checkout.
> /tmp/f/a$ f tim
> === 2014-07-22 ===
> 09:22:41 [4b720ef551] *CURRENT* test (user: michai tags: trunk)
> === 2014-01-01 ===
> 00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk)
> +++ no more data (2) +++
>

(That last line is a little confusing, IMO. Almost looks like an error.)


> The order of opening/committing are important; if the commit from
> workdir 'b' happens before the repo is opened in workdir 'a',
> everything seems to work OK.
>
> In the 1st session (without initial empty commit), more commits can be
> done from dir 'b', but these are not seen when updating in dir 'a'
> afterwards. The timeline in workdir 'a' does show the commits.
>

i think i'm going to wait for Andy's response, rather than try to wrap my
head around that ;).

-- 
- 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] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-22 Thread Michai Ramakers
On 22 July 2014 11:35, Michai Ramakers  wrote:
>
> while toying around with Andy Bradford's fix/analysis, found something
> else, which seems related to the no-initial-commit feature which is
> recent default in trunk.
>
> ...

of course, forgot something:

This is fossil version 1.30 [619fa857c9] 2014-07-19 19:20:25 UTC

(i.e. trunk of this moment)

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


[fossil-users] commits not seen on 2nd local worktree unless forcing initial commit

2014-07-22 Thread Michai Ramakers
Hello,

while toying around with Andy Bradford's fix/analysis, found something
else, which seems related to the no-initial-commit feature which is
recent default in trunk.

(FWIW, I know there have been flaws in this area before, and although
I am not a dev having/willing to deal with them, I agree with Jan that
'bugs happen', and a feature uncovering bugs or even introducing new
ones is not necessarily bad for that reason alone, if it eventually
results in a cleaner design. I don't know how well initial-commit-less
repos work with older fossil-versions, but I assume that has been
discussed or considered in detail elsewhere. )

Here are 2 typescripts; the first witout empty initial commit, and the
latter with forced initial commit. Everything is cleaned up in between
the 2 sessions.

In both cases, a repo is created, and it is opened as-is in 2
workdirs. A file is then added in workdir 'b', and an update is done
is workdir 'a'. In the first example, the update is not seen; in the
2nd example, everything is OK:

---( without initial commit: )---

/tmp$ mkdir f
/tmp$ cd f
/tmp/f$ f new f.f
project-id: bf874a5a154d7e572d99464d602a42bcb0dcf4bf
server-id:  c9f88d8904cedc4b7932c7c9832c3db8b6760d74
admin-user: michai (initial password is "7dfb91")
/tmp/f$ mkdir a b
/tmp/f$ cd a
/tmp/f/a$ f open ../f.f
project-name: 
repository:   /tmp/f/a/../f.f
local-root:   /tmp/f/a/
config-db:/home/michai/.fossil
project-code: bf874a5a154d7e572d99464d602a42bcb0dcf4bf
checkins: 0
/tmp/f/a$ cd ../b
/tmp/f/b$ f open ../f.f
project-name: 
repository:   /tmp/f/b/../f.f
local-root:   /tmp/f/b/
config-db:/home/michai/.fossil
project-code: bf874a5a154d7e572d99464d602a42bcb0dcf4bf
checkins: 0
/tmp/f/b$ f tim
+++ no more data (0) +++
/tmp/f/b$ date > thefile
/tmp/f/b$ f add thefile
ADDED  thefile
/tmp/f/b$ f ci -m test thefile
New_Version: c3450bfdff913112f6121b145540aa669d99e8eb
/tmp/f/b$ cd ../a
/tmp/f/a$ f up
/tmp/f/a$ f tim
=== 2014-07-22 ===
09:20:06 [c3450bfdff] test (user: michai tags: trunk)
+++ no more data (1) +++
/tmp/f/a$ ls
/tmp/f/a$

---( with forced initial commit: )---

/tmp$ mkdir f
/tmp$ cd f
/tmp/f$ date
Tue Jul 22 11:22:04 CEST 2014
/tmp/f$ f new --date-override 2014-01-01 f.f
project-id: 1f87142730004196e2388d27d2514fd06e8d9539
server-id:  b2b51507887bf5e0e0f9b899298f8d2ecc67c258
admin-user: michai (initial password is "a1757a")
/tmp/f$ mkdir a b
/tmp/f$ cd a
/tmp/f/a$ f open ../f.f
project-name: 
repository:   /tmp/f/a/../f.f
local-root:   /tmp/f/a/
config-db:/home/michai/.fossil
project-code: 1f87142730004196e2388d27d2514fd06e8d9539
checkout: b58cc4d9818973107a8acba469dda6edd4ba9683 2014-01-01 00:00:00 UTC
leaf: open
tags: trunk
comment:  initial empty check-in (user: michai)
checkins: 1
/tmp/f/a$ cd ../b
/tmp/f/b$ f open ../f.f
project-name: 
repository:   /tmp/f/b/../f.f
local-root:   /tmp/f/b/
config-db:/home/michai/.fossil
project-code: 1f87142730004196e2388d27d2514fd06e8d9539
checkout: b58cc4d9818973107a8acba469dda6edd4ba9683 2014-01-01 00:00:00 UTC
leaf: open
tags: trunk
comment:  initial empty check-in (user: michai)
checkins: 1
/tmp/f/b$ date > thefile
/tmp/f/b$ f add thefile
ADDED  thefile
/tmp/f/b$ f ci -m test thefile
New_Version: 4b720ef5510056c9ab365389e1bed9a6af78004b
/tmp/f/b$ cd ../a
/tmp/f/a$ f up
ADD thefile
---
updated-to:   4b720ef5510056c9ab365389e1bed9a6af78004b 2014-07-22 09:22:41 UTC
leaf: open
tags: trunk
comment:  test (user: michai)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
/tmp/f/a$ f tim
=== 2014-07-22 ===
09:22:41 [4b720ef551] *CURRENT* test (user: michai tags: trunk)
=== 2014-01-01 ===
00:00:00 [b58cc4d981] initial empty check-in (user: michai tags: trunk)
+++ no more data (2) +++
/tmp/f/a$ ls
thefile
/tmp/f/a$

---

The order of opening/committing are important; if the commit from
workdir 'b' happens before the repo is opened in workdir 'a',
everything seems to work OK.

In the 1st session (without initial empty commit), more commits can be
done from dir 'b', but these are not seen when updating in dir 'a'
afterwards. The timeline in workdir 'a' does show the commits.

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