On Thu, Mar 4, 2010 at 1:38 PM, D. Richard Hipp <d...@hwaci.com> wrote:
> Fossil repositories do not normally need to be "vacuumed".  The
> exception is when they have been newly constructed such as by clone -
> which vacuums automatically, or by the Git import tool.  (Does that
> Git import tool vacuum the repository when it is done?  I'm guessing
> not.)  It is also sometimes necessary to vacuum after you upgrade the
> "fossil" executable.  But for day-to-day operation Fossil maintains
> its compact size - similar to Hg, it seems.

You guessed correctly. At the moment the tool is pretty "dumb". It
leaves the construction of the fossil repo to the end user (via the
reconstruct subcommand). All it aimed to do is provide a clean
translation to fossil artifacts. I suppose it's probably time to do
the reconstruction also. Is there a reason the reconstruct subcommand
doesn't do a vacuum? I'd be happy to provide a patch if there isn't a
reason.

> On Mar 4, 2010, at 4:22 PM, pasqualinoferrentino-fos...@yahoo.it wrote:
>>       I must say that I was delighted from this news, because it
>> allowed me to test fossil on my current project, which is now hosted
>> in bitbucket to test fossil repository size performance on a
>> "real-world" project, medium sized, but not "toy".

I'm glad you were interested in my tool. I thought it was somewhat
strange that there weren't already converters out there.

>> Unfortunately it is a closed-source project, but I can give some
>> statistics: it is written in Java, it has 4568 changesets and the
>> repository size is
>> [...]
>> Repository Size:      112292864 bytes
>> Number Of Artifacts:  14122 (stored as 2430 full text and 11692 delta
>> blobs)
>> Uncompressed Artifact Size:   27536 bytes average, 388868844 bytes total
>> Compression Ratio:    34:10
>> Number Of Check-ins:  4067

I notice that the number you give and the number fossil reports don't
quite match up. Did the conversion happen correctly? If not would you
be willing to share some details about the repository (# of branches,
# of tags, # of merges (in particular merges involving more than 2
branches has not been tested), etc. no confidential details needed) so
I could work to fix the bug?

Thanks,

-B

>______________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to