Re: [fossil-users] Parent of the very first checkin?
On Sat, Dec 21, 2013 at 5:54 AM, Andy Bradford amb-fos...@bradfords.orgwrote: perhaps the root:trunk symbolic name would find it, but I was wrong. It finds c06edd231fc15d145a1c96c39b8fecdb79b33523 which is apparently where the current trunk began from a branch. Here's a workaround: [stephan@host:~/cvs/fossil/fossil]$ echo 'select uuid from blob order by rid limit 1;' | f sqlite3 a28c83647dfa805f05f3204a7e146eb1f0d90505 [stephan@host:~/cvs/fossil/fossil]$ f artifact a28c83647dfa805f05f3204a7e146eb1f0d90505 C initial\sempty\sbaseline D 2007-07-21T14:09:59 P R d41d8cd98f00b204e9800998ecf8427e U drh Z c62e3619f7c41ee77b33f00df8ec26f4 -- - 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] Parent of the very first checkin?
2013/12/21 Stephan Beal sgb...@googlemail.com: On Sat, Dec 21, 2013 at 5:54 AM, Andy Bradford amb-fos...@bradfords.org wrote: perhaps the root:trunk symbolic name would find it, but I was wrong. It finds c06edd231fc15d145a1c96c39b8fecdb79b33523 which is apparently where the current trunk began from a branch. Here's a workaround: [stephan@host:~/cvs/fossil/fossil]$ echo 'select uuid from blob order by rid limit 1;' | f sqlite3 a28c83647dfa805f05f3204a7e146eb1f0d90505 Simpler and somewhat dangerous (there is no guarantee that the first check-in will actually have rid=1): fossil update rid:1 You could also tag the first initial checking with anything you like, then you can use that tag in the future: fossil tag add mother rid:1 fossil update mother 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] Parent of the very first checkin?
On 21/12/13 09:30, Stephan Beal wrote: select uuid from blob order by rid limit 1; Oh, hadn't thought of that. Very nice. I'm writing a script to manipulate someone else's repository, so tagging it myself isn't an option --- I have to work with default functionality only. Right now I'm using the 'fossil json' API but it's missing a couple of things (tag values in the timeline, event timeline). I might switch to raw SQL. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs. --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ 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] Parent of the very first checkin?
On Sat, 21 Dec 2013 05:54:24 +0100, Andy Bradford
amb-fos...@bradfords.org wrote:
Thus said Richard Hipp on Fri, 20 Dec 2013 19:05:07 -0500:
http://www.fossil-scm.org/fossil/info/a28c83647d
Is there a command line option that will find this artifact? I thought
perhaps the root:trunk symbolic name would find it, but I was wrong. It
finds c06edd231fc15d145a1c96c39b8fecdb79b33523 which is apparently where
the current trunk began from a branch.
Of course the following works, but I have to guess at the number of
artifacts:
fossil timeline -n 10 | tail
actually, you don't need to guess any more since `n 0' now yields so whole
timeline. so
fossil timeline -n 0 |tail -2 | awk -F[][] 'NR == 1 {print $2}'
should yield the SHA1 hash of initial checkin (for recent versions of
`fossil' emitting the trailing `+++ end of timeline (10587) +++' message).
but I just think (repeat it until it sticks ;-):
http://en.wikipedia.org/wiki/Carthago_delenda_est) this is another
instance where fossil would profit from supporting incremental revision
numbers in the respective local repo so that one could just update to
revision no. 0.
j.
Thanks,
Andy
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] Parent of the very first checkin?
Thus said Stephan Beal on Sat, 21 Dec 2013 10:30:57 +0100: [stephan@host:~/cvs/fossil/fossil]$ echo 'select uuid from blob order by rid limit 1;' | f sqlite3 a28c83647dfa805f05f3204a7e146eb1f0d90505 Ok, I assumed it would involve finding the first rid, but wasn't certain that this was right. Thanks, Andy -- TAI64 timestamp: 400052b5cb34 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Incorrect branch content on import
Hi List I'm trying to move my dhcpcd git repository [1] to fossil [2]. While it works for the most part, it seems that the branches called trunk and dhcpcd-5 have the same commits, which is just wrong. I have successfully done a git export | git import to a new repository [3] to see if it's a git problem, but the end product is fine. Lastly, I did a fossil export to git [4] which now exhibits the same problems. So I must assume the problem is in fossil. I've tried versions 1.26 and 1.27. Is this something easily fixable? Can I provide any more help debugging it? One other thing of note, it seems that on import all commiters are me. While this is true, I would rather record the author on the git commit. Is this posible? Thanks Roy [1] http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=summary [2] http://roy.marples.name/fossil/dhcpcd/ [3] http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd-test/.git;a=summary [4] http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd-new/.git;a=summary ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] When modifying a file too quickly, it doesn't change
(Why yes, I am doing something moderately evil with Fossil...)
I have found a rather unpleasant-looking bug where if a file's content
changes too quickly, and its size does not change, it's not considered
to have changed. It smells as if Fossil is using a combination of the
file length and timestamp to determine whether the file has changed.
Test case follows:
echo Test data file
fossil add file
fossil commit file -m Ancestor # succeeds
echo Branch 1 file
fossil commit file -m Initial content # succeeds
echo Branch 2 file
fossil commit file -m Subsequent content # fails
This is on a repo where mtime-changes is unset. If I set it to 'off',
the test passes.
I think the fault is this chunk from vfile.c:
if( (chnged==0 || chnged==2 || chnged==4)
(useMtime==0 || currentMtime!=oldMtime) ){
/* check SHA1 hash here */
}
If the file size hasn't changed, then chnged is 0 as Fossil doesn't know
it's changed yet. If useMtime is 0 and the modification time falls
within the same second window as the original, then the condition never
fires and the SHA1 hash is never calculated.
I think that should be:
if( (chnged==0 || chnged==2 || chnged==4)
|| (useMtime currentMtime!=oldMtime) ){
...that is, check the SHA1 hash if the file is thought to be unchanged
*or* if useMtime is set *and* the mtime has in fact changed.
However I'm sufficiently unconfident about my analysis to actually go
and try it. Thoughts?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs. ---
│ Flon's Axiom
signature.asc
Description: OpenPGP digital signature
___
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] When modifying a file too quickly, it doesn't change
On Sat, Dec 21, 2013 at 09:21:25PM +, David Given wrote: I have found a rather unpleasant-looking bug where if a file's content changes too quickly, and its size does not change, it's not considered to have changed. It smells as if Fossil is using a combination of the file length and timestamp to determine whether the file has changed. Yes, it certainly uses mtime by default to skip the much more expensive hashing step. You can disable that from the settings. 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] When modifying a file too quickly, it doesn't change
On 21/12/13 21:24, Joerg Sonnenberger wrote: [...] Yes, it certainly uses mtime by default to skip the much more expensive hashing step. You can disable that from the settings. You mean it's *supposed* not to do the SHA1 hash by default? Isn't this horribly unsafe (because you'll miss changes, like is happening in my case)? I was assuming it was using the mtime to detect *changed* files, not *unchanged* files! -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs. --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ 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] When modifying a file too quickly, it doesn't change
On Sat, Dec 21, 2013 at 4:34 PM, David Given d...@cowlark.com wrote: On 21/12/13 21:24, Joerg Sonnenberger wrote: [...] Yes, it certainly uses mtime by default to skip the much more expensive hashing step. You can disable that from the settings. You mean it's *supposed* not to do the SHA1 hash by default? Isn't this horribly unsafe (because you'll miss changes, like is happening in my case)? The command is fossil setting mtime-changes off. Having mtime-changes on (the default) means that fossil will look for changed files by only examining the size and mtime. With it off, Fossil does a full SHA1 hash on every file in the repository. For a large repo with many files, mtime-changes off means that many operations are slow, because running SHA1 hashes on thousands of files takes significant time. Hence mtime-changes is off by default. Normally this does not cause problems, since it is very rare that a file will actually change content without either its mtime or is size changing. mtime-changes used to be off by default, which is manageable for projects of less than 1000 files on a fast workstation. The default got changed to on when people started using Fossil on larger projects. -- 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] When modifying a file too quickly, it doesn't change
On Sat, Dec 21, 2013 at 09:34:45PM +, David Given wrote: On 21/12/13 21:24, Joerg Sonnenberger wrote: [...] Yes, it certainly uses mtime by default to skip the much more expensive hashing step. You can disable that from the settings. You mean it's *supposed* not to do the SHA1 hash by default? Isn't this horribly unsafe (because you'll miss changes, like is happening in my case)? I was assuming it was using the mtime to detect *changed* files, not *unchanged* files! Well, it is looking for what files changed. If a file has potentially changed, it will compute the checksum. While it might be a good idea (and moderately simple) for fossil to support sub-second precision for mtime when the filesystem does so, for normal users it works extremely well. For other cases like fossil stat, you can force it to use hashes with --sha1sum. 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] When modifying a file too quickly, it doesn't change
On 21/12/13 22:00, Richard Hipp wrote: [...] For a large repo with many files, mtime-changes off means that many operations are slow, because running SHA1 hashes on thousands of files takes significant time. Hence mtime-changes is off by default. Normally this does not cause problems, since it is very rare that a file will actually change content without either its mtime or is size changing. The big gotcha, of course, is scripts, which typically perform several changes on similar files in very rapid succession --- that's precisely how I found this myself. I find myself very uneasy about having this defaulting to on. I have no objection to having the option there if people want it, but I do think that the *default* should be the safe option. Particularly since Fossil prides itself on safety. With my particular script I spotted the error because I ended up with an empty checkin and commit bailed. But if that file had been part of a multi-file checkin set, then it would have simply been silently omitted from the checkin and the work lost. As a concrete example: after changing my script to set it to off before starting, my test suite now fails. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs. --- │ Flon's Axiom signature.asc Description: OpenPGP digital signature ___ 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] Incorrect branch content on import
On 21/12/2013 21:11, Roy Marples wrote: I'm trying to move my dhcpcd git repository [1] to fossil [2]. While it works for the most part, it seems that the branches called trunk and dhcpcd-5 have the same commits, which is just wrong. By adding a commit to the dhcpcd-5 branch in git, exporting and then importing into fossil it now seems to work. I can live with that, as the commit is kinda valid using a more recent compiler than when the branch was done. I did this in different repos - dhcpcd-test, so the initial links are still valid incase anyone wants to debug this. I'll be doing that in the main repo tomorrow so I can move forward, but I'll make a backup first and post the link here incase someone really does want to fix it. I also exported it back to git and aside from committer name and the branch names having _ instead of say a . or a - it looks good. I assume the branch renaming is some kind of bug because the branch names look fine in fossil itself. A less important issue is that there seems to be no tie between trunk and git master in the fresh export (ie the git repo looks blank aside from the branch content). Lastly, before I dive into the fossil code to try and address the branch name export issue, does anyone know how fossil handles user names on import/export? Ideally I'd like to preserve the My Name m...@name.org in my current git repo @ import and also show this @ export. Thanks Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
