Re: [fossil-users] T-card checking too strict

[Jan Nijtmans]

2013/8/16 Ron Wilson :
> On Fri, Aug 16, 2013 at 10:55 AM, Richard Hipp  wrote:
>> No.  The correct fix is to put the T cards in the right order.
>
> I think what Jan is really proposing is that order check include the
> hash-keys so that a single control artifact could apply the same tag to more
> than 1 other artifact.

Thank you for all your feedback. Richard's explanation makes
it clear that the requirement is that all cards are sorted
lexicographically, so the best way to prove that this is a bug
is to construct a Control artifact that doens't violate
any requirement but still is rejected by fossil. Here it is:
 
But then why are the two branches not closed??
Simpy update fossil to this version:
 
and recompile and "fossil rebuild". Then the two branches
are closed as expected.

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] how to find a delta manifest?

[Isaac Jurado]

On Sat, Aug 17, 2013 at 8:36 PM, Stephan Beal  wrote:
>
> On Sat, Aug 17, 2013 at 6:50 PM, Stephan Beal  wrote:
>>
>> http://core.tcl.tk/tcl/artifact/5f37dcc36468eaa8
>
>
> i deconstructed the fossil repo and found not a single B card(!). i aborted 
> the deconstruct of the tcl repo at 11% and already had 9521 one of them.
>
> What makes tcl so special in this regard?

It's about backwards compatibility.  Fossil will not generate delta
manifest on commit unless there already are delta manifest on the
repository or you force it on the command line.  The TCL repository
was probably converted with a Fossil version that had delta manifest
support.

I guess that almost all Fossil binaries in use now understand B cards,
but as no one has committed to the Fossil repository with the
"--delta" option yet, you will not find any delta manifest in it.

Delta manifests are quite interesting because they follow the same
design concepts as Mercurial's delta storage.  I have already
mentioned it, but I have a Fossil branch that can generate delta
manifests on import.  However, I still don't have any place to publish
it.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] how to find a delta manifest?

[Stephan Beal]

On Sun, Aug 18, 2013 at 10:53 AM, Isaac Jurado  wrote:

> It's about backwards compatibility.  Fossil will not generate delta
> manifest on commit unless there already are delta manifest on the
> repository or you force it on the command line.
>

i had no idea there was a --delta option to commit - thanks for that tip.

I guess that almost all Fossil binaries in use now understand B cards,
> but as no one has committed to the Fossil repository with the
> "--delta" option yet, you will not find any delta manifest in it.
>

i don't want to be the first one to try ;), but i will use it on my the
libfossil repo for testing.


> Delta manifests are quite interesting because they follow the same
> design concepts as Mercurial's delta storage.  I have already
> mentioned it, but I have a Fossil branch that can generate delta
> manifests on import.  However, I still don't have any place to publish
> it.
>

i don't yet understand the benefit of a delta manifest except that they
save a few hundred (or thousand) lines of F-cards.

Do you know if it's possible to have a delta of a delta, or is a delta
always from a non-delta manifest? Parts of the code treat them as if there
can be any number of them (recursive cleanup in manifest_destroy()), but
some parts seem to imply that a delta cannot derive from a delta
(manifest_file_next()).

If you have a repo with deltas, may i have a copy of it? It would be very
useful for testing my delta manifest code.

:-?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] how to find a delta manifest?

[Joerg Sonnenberger]

On Sun, Aug 18, 2013 at 01:59:14PM +0200, Stephan Beal wrote:
> i don't yet understand the benefit of a delta manifest except that they
> save a few hundred (or thousand) lines of F-cards.

Exactly. This sums up a lot if you look at something like
http://pkgsrc.sonnenberger.org. You can fetch a copy from
ftp://ftp.netbsd.org/pub/NetBSD/misc/repositories/fossil/pkgsrc.fossil
or various mirrors near you.

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] how to find a delta manifest?

[Stephan Beal]

On Sun, Aug 18, 2013 at 2:04 PM, Joerg Sonnenberger  wrote:

> On Sun, Aug 18, 2013 at 01:59:14PM +0200, Stephan Beal wrote:
> > i don't yet understand the benefit of a delta manifest except that they
> > save a few hundred (or thousand) lines of F-cards.
>
> Exactly. This sums up a lot if you look at something like
> http://pkgsrc.sonnenberger.org. You can fetch a copy from
> ftp://ftp.netbsd.org/pub/NetBSD/misc/repositories/fossil/pkgsrc.fossil
> or various mirrors near you.


Ah, you and TCL are to blame ;). Yeah, i can see the benefit for that scale
of repo - a couple hundred lines of code is worth that (i don't think that
the delta handling actually takes up more than a couple routines). Now that
i have a delta in my sandbox repo, testing can move along. My thanks to you
and Isaac for the help.

[stephan@host:~/cvs/fossil/f2]$ ./f-resolve current
11f79a13dce4005d5446622f27801255b19989ea1769 current

[stephan@host:~/cvs/fossil/f2]$ ./f-acat current | ./f-mfparse -f=- -r
Parsing this manifest: -
MARKER: f-mfparse.c:43:test_parse_1(): Manifest type=MANIFEST, rid=1769,
uuid=11f79a13dce4005d5446622f27801255b19989ea
MARKER: f-mfparse.c:47:test_parse_1(): Trying to fetch baseline manifest
[20b54357ebd080aa541fb8725fe687a22f054f8f]
MARKER: f-mfparse.c:49:test_parse_1(): rc=FSL_RC_OK, Baseline=0x190c910
MARKER: f-mfparse.c:64:test_parse_1(): 88 files seen in manifest(s).
MARKER: f-mfparse.c:71:test_parse_1(): Trying to re-calculate R-card:
original=[6f94927663f297a98d2b5ed40a0f9298]
MARKER: f-mfparse.c:76:test_parse_1(): unshuffle rc=FSL_RC_OK
MARKER: f-mfparse.c:80:test_parse_1(): Re-calculated R-card:
[6f94927663f297a98d2b5ed40a0f9298]
Round-trip re-generated manifest (type=MANIFEST) from input file:
B 20b54357ebd080aa541fb8725fe687a22f054f8f
C
it\sturns\sout\scommit\ssupports\sa\s--delta\soption\sand\si\sneed\sa\sdelta\smanifest\sfor\stesting,\sso\shere's\sa\scomment-only\spatch\sfor\sdelta\stesting.
D 2013-08-18T12:10:24.622
F src/fsl_mf.c 60a24107e694f255f7d3077714cf403ebaa40f68
P 20b54357ebd080aa541fb8725fe687a22f054f8f
R 6f94927663f297a98d2b5ed40a0f9298
U stephan
Z aa128fb1baae44e252d16e5b1ae2e76e
Dumping mf to file [mf.out]


[stephan@host:~/cvs/fossil/f2]$ sha1sum mf.out
11f79a13dce4005d5446622f27801255b19989ea  mf.out

:-D

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

[fossil-users] Tickets without title...

[Jan Nijtmans]

Why do those two tickets don't have a title/status/severity/... any more?


I don't remember noting that before. Something happened in the last few days?

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] Tickets without title...

[Stephan Beal]

On Sun, Aug 18, 2013 at 2:40 PM, Jan Nijtmans wrote:

> Why do those two tickets don't have a title/status/severity/... any more?
> 
> 
> I don't remember noting that before. Something happened in the last few
> days?
>


That was most probably my fault - yesterday i went through the pending
moderation requests and i think i made a mess of it with those two tickets,
allowing some of the request and rejecting others. i didn't realize i had
done so until the 3rd or 4th change on the first ticket. i suspect that
when moderating i need to either allow a whole thread or none of the thread
to avoid this type of thing.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Tickets without title...

[Jan Nijtmans]

2013/8/18 Jan Nijtmans :
> Why do those two tickets don't have a title/status/severity/... any more?
> 
> 
> I don't remember noting that before. Something happened in the last few days?

Just a wild guess what could have happend:
- Someone without moderation rights submitted a ticket
- Someone else with moderation rights commented on that.
- The original ticket was rejected.

This way, the original ticket information is gone, but the
comments still exist so the ticket cannot be removed
completely. I'm not that familiar how ticket moderation
works, but this sounds like a bug to me.

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] Tickets without title...

[Stephan Beal]

On Sun, Aug 18, 2013 at 2:52 PM, Jan Nijtmans wrote:

> Just a wild guess what could have happend:
> - Someone without moderation rights submitted a ticket
> - Someone else with moderation rights commented on that.
> - The original ticket was rejected.
>

i can't say.


> This way, the original ticket information is gone, but the
> comments still exist so the ticket cannot be removed
> completely. I'm not that familiar how ticket moderation
> works, but this sounds like a bug to me.
>

The bug was probably in my workflow, but yes, it ideally shouldn't lead to
this type of thing. In the future i'll take care to reject comments on
rejected tickets. Part of the problem is that i didn't go through the
requests in order because i took care of the ones from the top of the
timeline before looking at the moderation page for the rest of the list (
http://fossil-scm.org/index.html/modreq).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Tickets without title...

[Jan Nijtmans]

2013/8/18 Stephan Beal :
> That was most probably my fault

I'm not convinced on that. If someone with moderation
rights comments on a ticket which is not approved
yet, this can happen as well.

Possible solution:
- If someone with moderation rights comments on a
  ticket which is not approved yet:
  - Either approve the ticket implicitly.
  - Or make the comment "pending approval" even
though the user has moderation rights
- If someone rejects a ticket submission, all
  comments should be rejected as well.

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] T-card checking too strict

[Stephan Beal]

On Sun, Aug 18, 2013 at 10:21 AM, Jan Nijtmans wrote:

> Simpy update fossil to this version:
>  
> and recompile and "fossil rebuild". Then the two branches
> are closed as expected.
>

A very minor nitpick: in this artifact:

http://www.fossil-scm.org/index.html/info/ce319b7898

the above code will also validate them if the T cards are swapped. Not a
big deal (not incompatible with any current repos/code), but from my
understanding of Richard's description a proper check would strcmp the
whole line (which is, in effect, what your original proposal suggests).
Because parsing modifies the original (replacing spaces with NUL bytes),
it's not possible to strcmp the whole input line, but a comparison routine
which looks a bit like this one would do the trick:

http://fossil.wanderinghorse.net/repos/f2/index.cgi/artifact/60a24107e694f255f7d3077714cf403ebaa40f68?ln=1467-1496

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Tickets without title...

[Stephan Beal]

On Sun, Aug 18, 2013 at 3:00 PM, Jan Nijtmans wrote:

> 2013/8/18 Stephan Beal :
> > That was most probably my fault
>
> I'm not convinced on that.


i'm the one who moderated that whole chain, i think, so i'm pretty sure
it's my fault ;).


> If someone with moderation
> rights comments on a ticket which is not approved
> yet, this can happen as well.
>

That might be - i'm not yet familiar with the inner workings of moderation.


> Possible solution:
> - If someone with moderation rights comments on a
>   ticket which is not approved yet:
>   - Either approve the ticket implicitly.
>   - Or make the comment "pending approval" even
> though the user has moderation rights
>

i don't have a problem with either, but would argue slightly more for the
latter simply because it's more difficult to import junk that way. i
remember my first moderation attempts - i commented on the tickets before
declining them (just to be polite), and that caused my comments to sync but
not the ticket (IIRC), which Richard pointed out to me. i don't remember
declining the ticket in this case, but did drop a comment or three.

- If someone rejects a ticket submission, all
>   comments should be rejected as well.
>

i think that's only possible if the ticket is rejected first? What happens
to approved comments if the ticket goes away? In this case i'm pretty sure
i moderated some of the comments first because they appeared first (top) in
the timeline.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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 from host A sometimes not seen on B

[Michai Ramakers]

Hello,

I'm probably doing somethng strange, but has anyone ever seen this behaviour:


1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline' doesn't show the recent commit
6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline'
7) on host C: do more work, and commit changes
8) on host 'S': 'fossil up'; now all recent commits are seen

Perhaps relevant info:
- autosync=1 on both sides
- host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd
- both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386
- fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC
- fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC

I can't reproduce this, but if someone has ideas to try the next time
this happens I'd be happy to try. I can rebuild fossil on one or both
hosts, but I have the feeling this is something very basic.

Related question: I typically use 'fossil up', and never 'fossil sync'
(or pull/push) in my workflow, working on 2 hosts on the same project
- should I?

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 from host A sometimes not seen on B

[Michai Ramakers]

Oh, perhaps useful: viewing the timeline on host S using the
web-interface (pointing to host S) at step (5) (or after step (6), not
sure) showed the commit I was expecting to see.

On 18 August 2013 17:20, Michai Ramakers  wrote:
> Hello,
>
> I'm probably doing somethng strange, but has anyone ever seen this behaviour:
>
>
> 1) on host S: clone project from host S (http://S/my_repo)
> 2) on host C: clone project from host S (http://S/my_repo)
> 3) on host C: do some work, and commit changes
> 4) on host S, 'fossil up'
> 5) on host S: 'fossil timeline' doesn't show the recent commit
> 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil 
> timeline'
> 7) on host C: do more work, and commit changes
> 8) on host 'S': 'fossil up'; now all recent commits are seen
>
> Perhaps relevant info:
> - autosync=1 on both sides
> - host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd
> - both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386
> - fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC
> - fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC
>
> I can't reproduce this, but if someone has ideas to try the next time
> this happens I'd be happy to try. I can rebuild fossil on one or both
> hosts, but I have the feeling this is something very basic.
>
> Related question: I typically use 'fossil up', and never 'fossil sync'
> (or pull/push) in my workflow, working on 2 hosts on the same project
> - should I?
>
> 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 from host A sometimes not seen on B

[Stephan Beal]

On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers wrote:

> 1) on host S: clone project from host S (http://S/my_repo)
> 2) on host C: clone project from host S (http://S/my_repo)
> 3) on host C: do some work, and commit changes
> 4) on host S, 'fossil up'
> 5) on host S: 'fossil timeline' doesn't show the recent commit
> 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil
> timeline'
> 7) on host C: do more work, and commit changes
> 8) on host 'S': 'fossil up'; now all recent commits are seen
>

It sounds almost like you have autosync turned off - do 'up' and 'pull'
show any network traffic?


> - autosync=1 on both sides
>

But you've already verified that.


> Related question: I typically use 'fossil up', and never 'fossil sync'
> (or pull/push) in my workflow, working on 2 hosts on the same project
> - should I?
>

That doesn't sound wrong. If autosync is on there is rarely a need for
push/pull. Do an 'up' when you start working, to make sure you aren't
working from what would become a fork, and it will sync/push when you
commit (if autosync is on).

i hope someone can help you resolve this - i also suspect that the problem
will turn out to be something simple/silly.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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 from host A sometimes not seen on B

[Michai Ramakers]

On 18 August 2013 17:43, Stephan Beal  wrote:
> On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers 
> wrote:
>>
>> 1) on host S: clone project from host S (http://S/my_repo)
>> 2) on host C: clone project from host S (http://S/my_repo)
>> 3) on host C: do some work, and commit changes
>> 4) on host S, 'fossil up'
>> 5) on host S: 'fossil timeline' doesn't show the recent commit
>> 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil
>> timeline'
>> 7) on host C: do more work, and commit changes
>> 8) on host 'S': 'fossil up'; now all recent commits are seen
>
>
> It sounds almost like you have autosync turned off - do 'up' and 'pull' show
> any network traffic?

Tbh I forgot - the error-situation is gone now, sadly.

>> Related question: I typically use 'fossil up', and never 'fossil sync'
>> (or pull/push) in my workflow, working on 2 hosts on the same project
>> - should I?
>
>
> That doesn't sound wrong. If autosync is on there is rarely a need for
> push/pull. Do an 'up' when you start working, to make sure you aren't
> working from what would become a fork, and it will sync/push when you commit
> (if autosync is on).

Right.

If it comes up again, I'll try to keep it as-is, if that's possible,
and post it on here - who knows.

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 from host A sometimes not seen on B

[Stestagg]

We had a similar situation last week:

Fossil server hosting many repos, two active clients on one repo.

Clients A and B were both working on the same branch simultaneously.

Client A commits (commit 1)
Client B tries to commit, gets conflict warning.
Client B runs fossil update
Client B commits successfully
Timeline on server shows two leaves with the same tag.
Client B never sees commit 1..
Running any combination of pull update rebuild does not work.  The commit
message for 1 is not present in the database.

In the end, I resolved this by re-cloning from the server.

Note we've been doing parallel commits on the branch for a while. And this
has only happened once, both clients use auto sync.

I was going to chalk this up to cosmic particles or similar, but it sounds
as of it might be related.

Thanks

Steve
 On 18 Aug 2013 16:51, "Michai Ramakers"  wrote:

> On 18 August 2013 17:43, Stephan Beal  wrote:
> > On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers 
> > wrote:
> >>
> >> 1) on host S: clone project from host S (http://S/my_repo)
> >> 2) on host C: clone project from host S (http://S/my_repo)
> >> 3) on host C: do some work, and commit changes
> >> 4) on host S, 'fossil up'
> >> 5) on host S: 'fossil timeline' doesn't show the recent commit
> >> 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil
> >> timeline'
> >> 7) on host C: do more work, and commit changes
> >> 8) on host 'S': 'fossil up'; now all recent commits are seen
> >
> >
> > It sounds almost like you have autosync turned off - do 'up' and 'pull'
> show
> > any network traffic?
>
> Tbh I forgot - the error-situation is gone now, sadly.
>
> >> Related question: I typically use 'fossil up', and never 'fossil sync'
> >> (or pull/push) in my workflow, working on 2 hosts on the same project
> >> - should I?
> >
> >
> > That doesn't sound wrong. If autosync is on there is rarely a need for
> > push/pull. Do an 'up' when you start working, to make sure you aren't
> > working from what would become a fork, and it will sync/push when you
> commit
> > (if autosync is on).
>
> Right.
>
> If it comes up again, I'll try to keep it as-is, if that's possible,
> and post it on here - who knows.
>
> 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] commits from host A sometimes not seen on B

[Clive Hayward]

I have experienced a similar problem as Steve on several occasions.  To fix
the problem I've been rebuilding the server repository and then merging on
the server.   Then the clients can pull to get in sync.


Clive


On Sun, Aug 18, 2013 at 9:25 AM, Stestagg  wrote:

> We had a similar situation last week:
>
> Fossil server hosting many repos, two active clients on one repo.
>
> Clients A and B were both working on the same branch simultaneously.
>
> Client A commits (commit 1)
> Client B tries to commit, gets conflict warning.
> Client B runs fossil update
> Client B commits successfully
> Timeline on server shows two leaves with the same tag.
> Client B never sees commit 1..
> Running any combination of pull update rebuild does not work.  The commit
> message for 1 is not present in the database.
>
> In the end, I resolved this by re-cloning from the server.
>
> Note we've been doing parallel commits on the branch for a while. And this
> has only happened once, both clients use auto sync.
>
> I was going to chalk this up to cosmic particles or similar, but it sounds
> as of it might be related.
>
> Thanks
>
> Steve
>  On 18 Aug 2013 16:51, "Michai Ramakers"  wrote:
>
>> On 18 August 2013 17:43, Stephan Beal  wrote:
>> > On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers 
>> > wrote:
>> >>
>> >> 1) on host S: clone project from host S (http://S/my_repo)
>> >> 2) on host C: clone project from host S (http://S/my_repo)
>> >> 3) on host C: do some work, and commit changes
>> >> 4) on host S, 'fossil up'
>> >> 5) on host S: 'fossil timeline' doesn't show the recent commit
>> >> 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil
>> >> timeline'
>> >> 7) on host C: do more work, and commit changes
>> >> 8) on host 'S': 'fossil up'; now all recent commits are seen
>> >
>> >
>> > It sounds almost like you have autosync turned off - do 'up' and 'pull'
>> show
>> > any network traffic?
>>
>> Tbh I forgot - the error-situation is gone now, sadly.
>>
>> >> Related question: I typically use 'fossil up', and never 'fossil sync'
>> >> (or pull/push) in my workflow, working on 2 hosts on the same project
>> >> - should I?
>> >
>> >
>> > That doesn't sound wrong. If autosync is on there is rarely a need for
>> > push/pull. Do an 'up' when you start working, to make sure you aren't
>> > working from what would become a fork, and it will sync/push when you
>> commit
>> > (if autosync is on).
>>
>> Right.
>>
>> If it comes up again, I'll try to keep it as-is, if that's possible,
>> and post it on here - who knows.
>>
>> 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 mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
Clive Hayward
___
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 from host A sometimes not seen on B

[Michai Ramakers]

did any of you (Steve/Clive) by any chance try committing once more (a
dummy-change or similar) on what Steve has named client A (the client
whose commit is never seen by the other host)?
(And if so, did both it and the missing commit show up?)

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 from host A sometimes not seen on B

[Clive Hayward]

Michai,

In more than one instance a subsequent commit was performed on one of the
clients (unaware that there was an issue).  That commit was visible to the
other client only after the server repository was rebuilt.

Clive


On Sun, Aug 18, 2013 at 10:28 AM, Michai Ramakers wrote:

> did any of you (Steve/Clive) by any chance try committing once more (a
> dummy-change or similar) on what Steve has named client A (the client
> whose commit is never seen by the other host)?
> (And if so, did both it and the missing commit show up?)
>
> Michai
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Clive Hayward
___
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 from host A sometimes not seen on B

[Stephan Beal]

On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward wrote:

> Michai,
>
> In more than one instance a subsequent commit was performed on one of the
> clients (unaware that there was an issue).  That commit was visible to the
> other client only after the server repository was rebuilt.
>

i've had a couple cases which sound similar but were explainable. i would
make a commit, the push would fail because my network was out or whatever,
and i wouldn't notice it. Later on i'd wonder where my commit was. That's
happened to me a handful of times over the years.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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 from host A sometimes not seen on B

[Clive Hayward]

Stephan,

Although I haven't been able to consistently reproduce the errors.  These
were definitely not network errors.

The steps involve.

1) Client A makes a commit.
2) Client B makes a commit - but is warned that they will fork.
3) Client B updates - but doesn't appear to get Client A's commit.
4) Client B commits with no error and the server forks.
5) Client C updates but only gets Client A or B's commit but not both.

At this point fossil rebuild on the server.  Clients can update and can see
the other leafs.


On Sun, Aug 18, 2013 at 10:58 AM, Stephan Beal wrote:

> On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward wrote:
>
>> Michai,
>>
>> In more than one instance a subsequent commit was performed on one of the
>> clients (unaware that there was an issue).  That commit was visible to the
>> other client only after the server repository was rebuilt.
>>
>
> i've had a couple cases which sound similar but were explainable. i would
> make a commit, the push would fail because my network was out or whatever,
> and i wouldn't notice it. Later on i'd wonder where my commit was. That's
> happened to me a handful of times over the years.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>



-- 
Clive Hayward
___
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 from host A sometimes not seen on B

[Stephan Beal]

On Sun, Aug 18, 2013 at 8:12 PM, Clive Hayward wrote:

> 5) Client C updates but only gets Client A or B's commit but not both.
>

All i can say to that is, "yeah, that's weird." Unfortunately not terribly
helpful.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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 from host A sometimes not seen on B

[Richard Hipp]

I think there is a bug in the sync algorithm that sometimes causes it to
quit before both sides are fully synced up.  But I don't yet have a
reproducible test case, so it is a hard problem to fix.

If you find a pair of repositories that are not fully syncing, please do
this:

(1) Make backup copies of the repositories on both sides of the exchange
and make them available to me for debugging.

(2) Run "fossil sync --verily" which is a heavy-duty sync that has a
simpler design that uses more bandwidth but which is also much more likely
to run to completion.  A single "fossil sync --verily" is probably
sufficient to get the two repos talking again after which ordinary syncs
(without the --verily option) should be sufficient again.

-- 
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] commits from host A sometimes not seen on B

[Clive Hayward]

Richard,

Would love to share repositories but would be violating my IP agreements:(
 So I'll need to try and trigger the problem with non-business data.

Thanks for the reference to "fossil sync --verily"


On Sun, Aug 18, 2013 at 11:36 AM, Richard Hipp  wrote:

> I think there is a bug in the sync algorithm that sometimes causes it to
> quit before both sides are fully synced up.  But I don't yet have a
> reproducible test case, so it is a hard problem to fix.
>
> If you find a pair of repositories that are not fully syncing, please do
> this:
>
> (1) Make backup copies of the repositories on both sides of the exchange
> and make them available to me for debugging.
>
> (2) Run "fossil sync --verily" which is a heavy-duty sync that has a
> simpler design that uses more bandwidth but which is also much more likely
> to run to completion.  A single "fossil sync --verily" is probably
> sufficient to get the two repos talking again after which ordinary syncs
> (without the --verily option) should be sufficient again.
>
> --
> D. Richard Hipp
> d...@sqlite.org
>



-- 
Clive Hayward
___
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] how to find a delta manifest?

[Isaac Jurado]

On Sun, Aug 18, 2013 at 1:59 PM, Stephan Beal  wrote:
> On Sun, Aug 18, 2013 at 10:53 AM, Isaac Jurado  wrote:
>>
>> It's about backwards compatibility.  Fossil will not generate delta
>> manifest on commit unless there already are delta manifest on the
>> repository or you force it on the command line.
>
>
> i had no idea there was a --delta option to commit - thanks for that tip.
>
>> I guess that almost all Fossil binaries in use now understand B cards,
>> but as no one has committed to the Fossil repository with the
>> "--delta" option yet, you will not find any delta manifest in it.
>
>
> i don't want to be the first one to try ;), but i will use it on my the
> libfossil repo for testing.
>
>>
>> Delta manifests are quite interesting because they follow the same
>> design concepts as Mercurial's delta storage.  I have already
>> mentioned it, but I have a Fossil branch that can generate delta
>> manifests on import.  However, I still don't have any place to publish
>> it.
>
>
> i don't yet understand the benefit of a delta manifest except that they save
> a few hundred (or thousand) lines of F-cards.
>
> Do you know if it's possible to have a delta of a delta, or is a delta
> always from a non-delta manifest? Parts of the code treat them as if there
> can be any number of them (recursive cleanup in manifest_destroy()), but
> some parts seem to imply that a delta cannot derive from a delta
> (manifest_file_next()).

As far as I've seen, delta manifest cannot be chained.  There is a
formula in the commit code that determines if a delta manifest is
worth using or not.  Therefore, when the parent of a delta manifest is
also a delta manifest, it will contain the F cards from the parent,
plus its own.

> If you have a repo with deltas, may i have a copy of it? It would be very
> useful for testing my delta manifest code.

I tested my improved import branch with the Django git repository,
which turned out contain a couple of very interesting cases I wasn't
even aware of when developing the first patches.  These imported
repositories weight almost 200MB, so I think it is better that I
manage to publish my branch so you can import whatever you want.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] how to find a delta manifest?

[Stephan Beal]

On Sun, Aug 18, 2013 at 10:02 PM, Isaac Jurado  wrote:

> As far as I've seen, delta manifest cannot be chained.  There is a
> formula in the commit code that determines if a delta manifest is
> worth using or not.  Therefore, when the parent of a delta manifest is
> also a delta manifest, it will contain the F cards from the parent,
> plus its own.
>

i've just finished porting add_mlink() and that code seems like it could
handle recursion (most of the code does), but i'm glad to get a
confirmation that i don't need to worry about recursion there. i guess i
can go replace some of those loops with assertions.


> > If you have a repo with deltas, may i have a copy of it? It would be very
> > useful for testing my delta manifest code.
>
> I tested my improved import branch with the Django git repository,
> which turned out contain a couple of very interesting cases I wasn't
> even aware of when developing the first patches.  These imported
> repositories weight almost 200MB, so I think it is better that I
> manage to publish my branch so you can import whatever you want.
>

Since you told me about the --delta commit flag, i've got all the
baselines/deltas i need now, but thank you :).

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

[fossil-users] John Ousterhout Featured Speaker at Tcl New & Proven User Conference in New Orleans (Tcl'2013)

[Andreas Kupries]

Founder of Tool Command Language to talk about Tcl Past, Present &
Future

Ann Arbor, MI -- August 16, 2013 -- The Tcl/Tk User Association, which
is celebrating over 20 years of innovation using the Tool Command
Language (Tcl), confirmed today that John Ousterhout will be a
Featured Speaker at the conference in New Orleans, LA from Sept 23-27,
2013.

 Ousterhout is the original developer of the Tcl and Tk programming
language, a combination of the Tool Command Language and the Tk
graphical user interface tookit (Tk).  His presentation will focus on
the evolution of Tcl/Tk from its original language format created at
the University of California Berkeley to the most robust and
easy-to-learn dynamic programming language that seamlessly powers
today's applications. He is also the author of Tcl and the Tk ToolKit
(2nd Edition).

"John started a revolution born out of frustration," says Clif Flynt,
President, Tcl Community Association and author of Tcl/Tk: A
Developer's Guide. "Before Tcl, programmers devised their own
languages that were intended to be embedded into applications. By
creating Tcl/Tk, John created a language for rapid prototyping that
works immediately."

The Tcl New and Proven user conference will feature several Tcl
experts including Jeff Hobbs, Chief Technical Officer at ActiveState,
Gerald Lester, creator of Tcl Web Services and a keynote speech by
Karl Lehenbauer of FlightAware.com.  Programmers attending the
conference will learn the best practices for using Tcl's new
object-oriented commands and widgets as well as seeing new
applications and techniques in the fields ranging from business
applications to health, aerospace and beyond.

"The Tcl New & Proven User Conference will be focusing on innovation
throughout the years," says Flynt. "We are very pleased to have two of
the people who helped create the Tcl we know today at our 20th
conference."

Interested in attending the Tcl conference? Go to
http://www.tcl.tk/community/tcl2013/ to register. Learn more about
Tcl/Tk by visiting the Tcl Developer Xchange http://www.tcl.tk/ where
you can download Tcl 8.6 and a free trial of TDK 5 (Tcl Dev Kit).

###

About Tcl/Tk  (http://www.tcl.tk/)

Celebrating over 20 years of providing rapid prototyping, Tool Command
Language (Tcl) is an open source, robust, powerful and easy-to-learn
dynamic programming language ideal for today's web and desktop
applications, networking, administration, and testing. Tk is a
graphical user interface toolkit that enables the development of
native-looking GUIs on multiple platforms such as Windows, Mac OS X
and Linux. The combination of Tcl and the Tk GUI toolkit is referred
to as Tcl/Tk..
 
The vibrant Tcl user community comes together on the Tcl Developer
Xchange website hosted by ActiveState (http://www.tcl.tk/), which
provides a variety of resources for programmers working with Tcl/Tk to
increase their productivity and share ideas. Worldwide Tcl
conferences, Tcl/Tk downloads and access to the Tcler's Wiki are all
available online at the Tcl Developer Xchange.  The latest books,
tutorials and demos are also accessible from this site along with the
Tcl core development team that steers the ongoing evolution of the
language.


Contact:
Amy Hesser
Hesser Communications Group
a...@hessercommunications.com
312-933-8324

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