On Thu, Dec 02, 2010 at 05:06:03PM +0800, Kumar wrote:
My work git repo is 2.8GB in size. During the first stage of the import,
the fossil file went to about 8.4GB, but after the vacuuming, it shrank
to the same 2.8GB. Sweet!
Ok, I gotta ask, what is *in* your repo that it's 2.8 GIGABYTES in
:D I knew someone would ask that!
Its not all source (as if I had to say that). There are some media
files tracked as well (images, audio clips and video clips)
that are part of the shipping product .. and about 3 years worth
history of those.
-Kumar
On Thu, Dec 2, 2010 at 5:08 PM, Zed A. Shaw
On Thu, Dec 2, 2010 at 4:06 AM, Kumar srikuma...@gmail.com wrote:
I've been using fossil for my personal work for a few months now,
but never had the chance to try it on a large project. After seeing the
new git import feature, I decided to give it a shot and .. whoa!
My work git repo is
On Thu, Dec 02, 2010 at 09:15:55AM -0500, Richard Hipp wrote:
FWIW, I'm thinking I should rename the import command to git-import - in
order to allow future expansion with other import schemes. Similarly,
export should be renamed git-export. Or, maybe there is a secondary
command to specify
On Thu, Dec 02, 2010 at 09:15:55AM -0500, Richard Hipp wrote:
Q2: fossil ui is nice. However, I'm missing search - like what git gui
gives. What do fossil-ites use for searching the repo? Just straight
database search?
SQLite has a great full-text search engine built in. I've long
On Thu, 2 Dec 2010 15:33:26 +0100
Joerg == Joerg Sonnenberger wrote:
Joerg Strictly speaking, it is git-fast-import as that's the input
Joerg stream it is reading. Either that or git-import looks best too
Joerg me.
+1
Moreover, I do not think there is need for e.g. git import svn
etc.
Hello,
fossil import git
fossil import svn
fossil import hg
And so forth Thoughts?
In my opinion, this is the most correct option for several reasons:
1- Do not pollute the global namespace
2- Make it easier for everyone that is not going to use the option
fossil import git
fossil import svn
fossil import hg
And so forth Thoughts?
If the format of the input stream can be auto-detected, then it can simply
be fossil import can't it? You'll only need to specify format explicitly
for the export I think.
Q1: Rgd git
On Thu, Dec 2, 2010 at 4:36 PM, Ramon Ribó ram...@compassis.com wrote:
About the full text search:
- Size is important. At least for some uses. It is common to copy
fossil repositories as files from one computer to another. At the same
time, one repository can have multiple copies.
One
On Thu, Dec 2, 2010 at 10:21 AM, Gour g...@atmarama.net wrote:
On Thu, 2 Dec 2010 15:33:26 +0100
Joerg == Joerg Sonnenberger wrote:
Joerg Strictly speaking, it is git-fast-import as that's the input
Joerg stream it is reading. Either that or git-import looks best too
Joerg me.
+1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/2010 09:36 AM, Ramon Ribó wrote:
In my opinion, this is the most correct option for several reasons:
1- Do not pollute the global namespace
2- Make it easier for everyone that is not going to use the option
(most of the users), and
SQLite has a great full-text search engine built in. I've long thought that
it would be great to add an interface to this in Fossil. We could index
diffs for all check-ins, all wiki, all tickets, all Blog entries, etc, and
then have a Google-like interface for searching for things. Of
David Shinn wrote:
Because fossil stores artifacts as zlib compressed deltas, full text
searching
using the existing fossil SQLite database is not possible. One would
either have
to create a separate database containing the full set of artifacts or
create a
program to reconstruct each
13 matches
Mail list logo
