On Fri, Oct 4, 2013 at 8:52 AM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Oct 4, 2013 at 6:27 AM, Ron Aaron r...@ronware.org wrote:
I have a large-ish repo, and after cloning it and updating some files, I
try to commit ... and get this message. I did already try fossil
rebuild to no
On Fri, Oct 4, 2013 at 8:57 AM, Stephan Beal sgb...@googlemail.com wrote:
Hmmm... we might need you to add some printfs() to fossil to debug this
one, unless there's a switch i'm unaware of to dump the manifest out before
committing.
i need to leave for a while, but here's something we can
Sorry, Ron: 2nd arg is pBlob, not pOut.
(mobile phone - please excuse brevity and typos)
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On Oct 4, 2013 9:17 AM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Oct 4, 2013 at 8:57 AM, Stephan Beal
2013/10/4 Stephan Beal sgb...@googlemail.com:
On Fri, Oct 4, 2013 at 8:57 AM, Stephan Beal sgb...@googlemail.com wrote:
Hmmm... we might need you to add some printfs() to fossil to debug this
one, unless there's a switch i'm unaware of to dump the manifest out before
committing.
Shouldn't
On Fri, Oct 4, 2013 at 11:30 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
Shouldn't the error-message in this case be more helpful anyway? Something
like:
http://fossil-scm.org/index.html/info/1eb438d61a
That's essentially how libfossil reports the errors for this case. At this
point
On Fri, Oct 4, 2013 at 12:10 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
Fully agreed! I also don't think that the parser is the problem, maybe
it's a bug somewhere else which does not properly fossilize some
field which ends up in the manifest later. My hope is that the
That's my
On Fri, Oct 4, 2013 at 12:13 PM, Richard Hipp d...@sqlite.org wrote:
Doesn't the -n option cause the manifest to be printed on standard output?
Quite possibly so - never used it :/.
In any case, i'm cloning the repo now (going a bit slowly) and will report
back as soon as i know something
On Fri, Oct 4, 2013 at 12:19 PM, Stephan Beal sgb...@googlemail.com wrote:
In any case, i'm cloning the repo now (going a bit slowly) and will report
back as soon as i know something concrete (and will report whether or not
-n spits out the manifest).
Follow-up: it's not the debugging which
On Fri, Oct 4, 2013 at 1:53 PM, Stephan Beal sgb...@googlemail.com wrote:
Follow-up: it's not the debugging which is taking so long, but the
reproduce/build process (cloning a remote site) has been running for about
80 minutes now and i have no idea how long it will run.
@Ron: this has prio
On Fri, Oct 4, 2013 at 2:22 PM, Stephan Beal sgb...@googlemail.com wrote:
... lots of file diffs and the big RID diff between the current and prev
commits implies lots of changes were made.
And...
[stephan@host:~/cvs/fossil/ron]$ ../libfossil/f-acat tip |
../libfossil/f-mfparse -r
Parsing
2013/10/4 Stephan Beal sgb...@googlemail.com:
On Fri, Oct 4, 2013 at 2:22 PM, Stephan Beal sgb...@googlemail.com wrote:
... lots of file diffs and the big RID diff between the current and prev
commits implies lots of changes were made.
I did the same, and everything looks fine. But it indeed
On Fri, Oct 4, 2013 at 3:00 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
Noting that both Stephan and I tried it on a 64-bit machine with a lot
of memory, could this be an unchecked memory overflow somewhere?
i'm also working on a repro in a 32-bit vm in parallel. In theory a
malloc failure
On Fri, Oct 4, 2013 at 3:01 PM, Stephan Beal sgb...@googlemail.com wrote:
i'm also working on a repro in a 32-bit vm in parallel. In theory a
malloc failure is not possible because fossil_malloc() aborts on alloc
error, but we do have a few places which use malloc()/free() instead of
On Fri, Oct 4, 2013 at 3:01 PM, Stephan Beal sgb...@googlemail.com wrote:
i'm also working on a repro in a 32-bit vm in parallel. In theory a
malloc failure is not possible because fossil_malloc() aborts on alloc
error, but we do have a few places which use malloc()/free() instead of
On 10/04/2013 04:24 PM, Stephan Beal wrote:
@Ron: which fossil version are you on, and what platform?
I'm using fossil 816e893d3b on Linux Mint 15 64bit (kernel 3.8.0-30-generic)
--
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html
On Fri, Oct 4, 2013 at 3:28 PM, Ron Aaron r...@ronware.org wrote:
I'm using fossil 816e893d3b on Linux Mint 15 64bit (kernel
3.8.0-30-generic)
Bummer: still works for me :(
[stephan@host:~/cvs/fossil/ron]$ f version
This is fossil version 1.27 [816e893d3b] 2013-10-04 02:50:26 UTC
ron@monster ~/proj/mtrweb $ fossil test-integrity
10826 non-phantom blobs (out of 10826 total) checked: 0 errors
ron@monster ~/proj/mtrweb $ fossil test-integrity --parse
10826 non-phantom blobs (out of 10826 total) checked: 0 errors
22 total control artifacts
6 manifests
16 clusters
sigh
2013/10/4 Stephan Beal sgb...@googlemail.com:
the only commit which can legally have a empty P-card is the initial commit
(or one without a parent, but i think that's only possible on the first
commit?).
An empty P-card (or a manifest without a P-card) is allowed for any
manifest, but then it
Ron, can you run:
sqlite3 .fslckout '.dump v%'
And post make that output available to us?
The .fslckout file should be at the root of your check-out. It might be
called _FOSSIL_ if your checkout was originally opened with a much older
version of Fossil.
--
D. Richard Hipp
d...@sqlite.org
On Fri, Oct 4, 2013 at 3:42 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
An empty P-card (or a manifest without a P-card) is allowed for any
manifest, but then it shouldn't have a space after the P (it would look
strange in the timeline, here is one:
Done, you can pick it up here: http://ronware.org/dump.sql.gz
Thanks!
On 10/04/2013 04:44 PM, Richard Hipp wrote:
sqlite3 .fslckout '.dump v%'
--
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html
___
fossil-users
On Fri, Oct 4, 2013 at 9:50 AM, Ron Aaron r...@ronware.org wrote:
Done, you can pick it up here: http://ronware.org/dump.sql.gz
That looks ok. What does the following query against the repository give:
SELECT uuid FROM blob WHERE rid=15513;
It should yield a SHA1 hash, which will
On Fri, Oct 4, 2013 at 3:50 PM, Ron Aaron r...@ronware.org wrote:
Done, you can pick it up here: http://ronware.org/dump.sql.gz
i think what Richard wanted there was:
INSERT INTO vvar VALUES('checkout','15513');
So that we can check:
[stephan@host:~/cvs/fossil/ron]$ echo select uuid from
2013/10/4 Ron Aaron r...@ronware.org:
Done, you can pick it up here: http://ronware.org/dump.sql.gz
Fossil code:
vid = db_lget_int(checkout, 0);
zParentUuid = db_text(0, SELECT uuid FROM blob WHERE rid=%d, vid);
From the dump:
INSERT INTO vvar VALUES('checkout','15513');
So the
On Fri, Oct 4, 2013 at 4:03 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
sqlite SELECT * FROM blob where rid=15513
lol... all of us racing at once to say the same thing. At least the answers
are consistent, though ;).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
Indeed, it gives an empty string.
On 10/04/2013 05:02 PM, Richard Hipp wrote:
SELECT uuid FROM blob WHERE rid=15513;
--
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html
___
fossil-users mailing list
On 10/04/2013 05:02 PM, Stephan Beal wrote:
echo select rid from blob where
uuid='6c0d3704e381430edaef8424b1c1d8d059325a65'; | fossil sqlite
For me it's 10798
--
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html
On 10/04/2013 05:03 PM, Jan Nijtmans wrote:
2013/10/4 Ron Aaron r...@ronware.org:
Done, you can pick it up here: http://ronware.org/dump.sql.gz
Fossil code:
vid = db_lget_int(checkout, 0);
zParentUuid = db_text(0, SELECT uuid FROM blob WHERE rid=%d, vid);
From the dump:
INSERT
Interestingly, select max(rid) from blob gives me 10826...
On 10/04/2013 05:02 PM, Richard Hipp wrote:
On Fri, Oct 4, 2013 at 9:50 AM, Ron Aaron r...@ronware.org
mailto:r...@ronware.org wrote:
Done, you can pick it up here: http://ronware.org/dump.sql.gz
That looks ok. What does the
On Fri, Oct 4, 2013 at 4:07 PM, Ron Aaron r...@ronware.org wrote:
On 10/04/2013 05:02 PM, Stephan Beal wrote:
echo select rid from blob where
uuid='6c0d3704e381430edaef8424b1c1d8d059325a65'; | fossil sqlite
For me it's 10798
Somehow the record of your checkout version and the actual
2013/10/4 Ron Aaron r...@ronware.org:
Indeed, it gives an empty string.
Then I have a theory what happened. My guess is that you
cloned the repository and opened it. Later you cloned the
repository again (which got different row-id's), storing it
in the exact original location. Then the row-id's
On Fri, Oct 4, 2013 at 4:10 PM, Ron Aaron r...@ronware.org wrote:
Interestingly, select max(rid) from blob gives me 10826...
The RIDs aren't 100% dependable as a point of reference, though. They are
sequential but not necessarily in increments of one. In theory the
highest-number RID must
On Fri, Oct 4, 2013 at 10:09 AM, Ron Aaron r...@ronware.org wrote:
So, Ron, can you try:
$fossil sqlite
sqlite SELECT * FROM blob where rid=15513
it's blank (empty) for me.
Blank as in the row does not exist, or blank in the sense that the row
exists but contains no content?
Don't know, I'll have to try and see. I can't recall doing that, but
it's certainly possible.
On 10/04/2013 05:12 PM, Jan Nijtmans wrote:
2013/10/4 Ron Aaron r...@ronware.org:
Indeed, it gives an empty string.
Then I have a theory what happened. My guess is that you
cloned the repository and
On Fri, Oct 4, 2013 at 4:21 PM, Ron Aaron r...@ronware.org wrote:
Well, boy howdy! That seems to have cured it.
:-D
Somehow I must have done Something Bad, but not clear just what it may
have been...
Jan's hypothesis sounds better than anything i can come up with. It was, in
any case,
Well, boy howdy! That seems to have cured it.
Somehow I must have done Something Bad, but not clear just what it may
have been...
Thanks to all of you for your help
Ron
On 10/04/2013 05:12 PM, Stephan Beal wrote:
On Fri, Oct 4, 2013 at 4:07 PM, Ron Aaron r...@ronware.org
On Fri, Oct 4, 2013 at 4:25 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Oct 4, 2013 at 4:21 PM, Ron Aaron r...@ronware.org wrote:
Well, boy howdy! That seems to have cured it.
:-D
Somehow I must have done Something Bad, but not clear just what it may
have been...
Jan's
On Fri, Oct 4, 2013 at 4:29 PM, Stephan Beal sgb...@googlemail.com wrote:
You did a rebuild in the middle, too, which might have further changed the
RIDs (they get regenerated during a rebuild, and not necessarily in the
same order as before). The rebuild didn't _cause_ this, but might have
On Fri, Oct 4, 2013 at 10:32 AM, Stephan Beal sgb...@googlemail.com wrote:
New theory! @Jan: please help me out here:
fossil rebuild -R repo
from outside the checkout could change the RIDs out from under any
checkouts.
I don't think rebuild changes RIDs. The RIDs are set by the BLOB
2013/10/4 Richard Hipp d...@sqlite.org:
On Fri, Oct 4, 2013 at 10:32 AM, Stephan Beal sgb...@googlemail.com wrote:
I don't think rebuild changes RIDs. The RIDs are set by the BLOB table and
BLOB is not changed by a rebuild.
I was about to answer the same: A clone is the only thing I know that
On Fri, Oct 4, 2013 at 4:35 PM, Richard Hipp d...@sqlite.org wrote:
I don't think rebuild changes RIDs. The RIDs are set by the BLOB table
and BLOB is not changed by a rebuild.
Good to know. i thought (haven't ported that far yet) that a rebuild
reconstructed the whole blob table one
On Fri, Oct 4, 2013 at 4:21 PM, Ron Aaron r...@ronware.org wrote:
Well, boy howdy! That seems to have cured it.
Next time it won't take so long:
http://www.fossil-scm.org/index.html/info/7bf9fdb068
that adds a check for this specific case and fails earlier in the process.
--
-
What can I do about this error?
I have a large-ish repo, and after cloning it and updating some files, I
try to commit ... and get this message. I did already try fossil
rebuild to no effect.
--
For confidential messages, please use my GnuPG key
http://ronware.org/gpg_key.html
On Sun, Jul 8, 2012 at 10:09 PM, Thomas Stover c...@thomasstover.com wrote:
the problem was apparently that fossil was storing absolute
file names,
That sounds like a serious problem. Fossil *should* store all filenames
relative to the root of the repository file hierarchy. Can you
On Mon, Jul 9, 2012 at 4:09 AM, Thomas Stover c...@thomasstover.com wrote:
In my case the problem was apparently that fossil was storing absolute
file names, which were now different. So even though I didn't rename
Are you sure this has to do with absolute file names? We had a bug a week
or
On Monday, July 9, 2012 12:51pm, Stephan Beal sgb...@googlemail.com said:
Are you sure this has to do with absolute file names? We had a bug a week or
two ago with a malformed
manifest, and you might be seeing that. Can you try this with the latest
version, and paste in any error
Forgoing the sordid tale of why I had to do this, to commit changes
from a laptop, I had to copy my fossil project directories over to
another computer with functioning internet connectivity. Once there, I
tried a fossil commit only to be hit with a manifest file is
malformed error. Some searching
fossil.exe: manifest file (3967) is malformed
I don't think this will be of much help but I have a reproducible test
case that results in such an error. I tested it on Russian Windows 7 x64
only. Initial script is in the attachment, encoding is UTF-8 without a
byte order mark (cmd.exe chokes
I've experienced this before and it turns out the work-around is simple.
It normally happens when you rename file1, modify file2, then attempt to commit
file2 without including file1 in the commit. If you commit file1 first, things
work and the error vanishes.
It would be helpful if you
Sean Chittenden wrote:
I've experienced this before and it turns out the work-around is simple.
It normally happens when you rename file1, modify file2, then attempt to
commit file2
without including file1 in the commit. If you commit file1 first, things work
and the
error vanishes.
Hi,
Graeme Gill wrote:
fossil.exe: manifest file (3967) is malformed
Has anyone got any suggestion on where to go with this ?
Is there a command to fix a corrupted fossil databases ?
Is there a way of diagnosing where/why/what is malformed about the manifest ?
Should I just give up and use a
On Thu, May 5, 2011 at 8:41 PM, Graeme Gill grae...@argyllcms.com wrote:
Hi,
I've been using fossil happily for a few weeks, but suddenly have a
problem.
After renaming a couple of files, I can't do a commit anymore:
fossil commit afiles
vim ci-comment-D69892D388C2.txt
New_Version:
I just did fossil update $ID in order to build a particular version of
the source and I find no manifest file in the checkout directory. The
documentation on the website still talks about a manifest file, so has
something changed in recent versions of fossil? Why don't I have a
manifest
On Fri, Feb 18, 2011 at 12:54:23PM -0500, Bill Whiting wrote:
I just did fossil update $ID in order to build a particular version of
the source and I find no manifest file in the checkout directory. The
documentation on the website still talks about a manifest file, so has
something
54 matches
Mail list logo
