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

2013-08-18 Thread 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

Re: [fossil-users] how to find a delta manifest?

2013-08-18 Thread 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

Re: [fossil-users] how to find a delta manifest?

2013-08-18 Thread 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

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

2013-08-18 Thread 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 syn

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

2013-08-18 Thread 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 copie

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

2013-08-18 Thread 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/sgb

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

2013-08-18 Thread 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.

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

2013-08-18 Thread 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 coup

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

2013-08-18 Thread 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 yo

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

2013-08-18 Thread 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 __

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

2013-08-18 Thread 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 la

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

2013-08-18 Thread 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 s

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

2013-08-18 Thread 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

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

2013-08-18 Thread 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 s

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

2013-08-18 Thread 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

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

2013-08-18 Thread 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: 'fossi

Re: [fossil-users] Tickets without title...

2013-08-18 Thread 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 ticke

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

2013-08-18 Thread 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

Re: [fossil-users] Tickets without title...

2013-08-18 Thread 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:

Re: [fossil-users] Tickets without title...

2013-08-18 Thread 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 tic

Re: [fossil-users] Tickets without title...

2013-08-18 Thread 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 las

Re: [fossil-users] Tickets without title...

2013-08-18 Thread 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.

[fossil-users] Tickets without title...

2013-08-18 Thread 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

Re: [fossil-users] how to find a delta manifest?

2013-08-18 Thread 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

Re: [fossil-users] how to find a delta manifest?

2013-08-18 Thread 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 cop

Re: [fossil-users] how to find a delta manifest?

2013-08-18 Thread 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 -

Re: [fossil-users] how to find a delta manifest?

2013-08-18 Thread 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 alre

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

2013-08-18 Thread 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 >