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, exporti
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,
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
On Sat, Dec 21, 2013 at 4:34 PM, 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 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 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 ti
(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 timesta
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
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
On Sat, 21 Dec 2013 05:54:24 +0100, Andy Bradford
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 fin
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
2013/12/21 Stephan Beal :
> On Sat, Dec 21, 2013 at 5:54 AM, Andy Bradford
> 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 wo
On Sat, Dec 21, 2013 at 5:54 AM, Andy Bradford 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/f
13 matches
Mail list logo
