2013/8/16 Ron Wilson ronw.m...@gmail.com:
On Fri, Aug 16, 2013 at 10:55 AM, Richard Hipp d...@sqlite.org 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
On Sat, Aug 17, 2013 at 8:36 PM, Stephan Beal sgb...@googlemail.com wrote:
On Sat, Aug 17, 2013 at 6:50 PM, Stephan Beal sgb...@googlemail.com wrote:
http://core.tcl.tk/tcl/artifact/5f37dcc36468eaa8
i deconstructed the fossil repo and found not a single B card(!). i aborted
the
On Sun, Aug 18, 2013 at 10:53 AM, Isaac Jurado dipto...@gmail.com 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
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
On Sun, Aug 18, 2013 at 2:04 PM, Joerg Sonnenberger jo...@britannica.bec.de
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
Why do those two tickets don't have a title/status/severity/... any more?
http://fossil-scm.org/index.html/tktview?name=6aeda5a5f3
http://fossil-scm.org/index.html/tktview?name=311671db59
I don't remember noting that before. Something happened in the last few days?
Regards,
Jan
On Sun, Aug 18, 2013 at 2:40 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
Why do those two tickets don't have a title/status/severity/... any more?
http://fossil-scm.org/index.html/tktview?name=6aeda5a5f3
http://fossil-scm.org/index.html/tktview?name=311671db59
I don't remember
2013/8/18 Jan Nijtmans jan.nijtm...@gmail.com:
Why do those two tickets don't have a title/status/severity/... any more?
http://fossil-scm.org/index.html/tktview?name=6aeda5a5f3
http://fossil-scm.org/index.html/tktview?name=311671db59
I don't remember noting that before. Something
On Sun, Aug 18, 2013 at 2:52 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
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,
2013/8/18 Stephan Beal sgb...@googlemail.com:
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
On Sun, Aug 18, 2013 at 10:21 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
Simpy update fossil to this version:
http://fossil-scm.org/index.html/info/55cacfcace
and recompile and fossil rebuild. Then the two branches
are closed as expected.
A very minor nitpick: in this artifact:
On Sun, Aug 18, 2013 at 3:00 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2013/8/18 Stephan Beal sgb...@googlemail.com:
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
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:
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 m.ramak...@gmail.com wrote:
Hello,
I'm probably doing somethng strange,
On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.comwrote:
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
On 18 August 2013 17:43, Stephan Beal sgb...@googlemail.com wrote:
On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.com
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,
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
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 stest...@gmail.com wrote:
We had a
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
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
On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward haywa...@chayward.comwrote:
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.
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
On Sun, Aug 18, 2013 at 8:12 PM, Clive Hayward haywa...@chayward.comwrote:
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/
On Sun, Aug 18, 2013 at 1:59 PM, Stephan Beal sgb...@googlemail.com wrote:
On Sun, Aug 18, 2013 at 10:53 AM, Isaac Jurado dipto...@gmail.com wrote:
It's about backwards compatibility. Fossil will not generate delta
manifest on commit unless there already are delta manifest on the
repository
On Sun, Aug 18, 2013 at 10:02 PM, Isaac Jurado dipto...@gmail.com 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
25 matches
Mail list logo
