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:
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
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
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
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.
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
(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
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
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,
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
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
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
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
13 matches
Mail list logo
