Re: [fossil-users] Merge tracking tests in a blog entry, some questions

[Paul Hammant]

Thanks Stephen & Richard.
___
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] Merge tracking tests in a blog entry, some questions

[Stephan Beal]

On Sat, Jun 18, 2016 at 9:53 PM, Richard Hipp  wrote:

> Performance problems come about more due to the number of files in a
> single check-out.  Most projects have a few thousand source files, for
> which Fossil works great.  When the number of files in a single
> revision gets into the hundreds of thousands, then some operations can
> become sluggish.
>

Also, the diff/merge bits need an amount of memory proportional to, but
greater than, a file's size (potentially 2-3x), so storing very large files
(e.g. CD images or huge multimedia blobs) may cause out-of-memory
conditions on machines with limited memory/swap space.

-- 
- 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] Merge tracking tests in a blog entry, some questions

[Richard Hipp]

On 6/18/16, Paul Hammant  wrote:
>
> Learning curve for Fossil - about an hour.  Curiosities:
>
>- Having a database name rather than just a .git or .svn folder
>convention
>- The 'open' step.

These result from the fact that a single Fossil repository can have
multiple simultaneously open check-outs.  To do the same in something
like Git, you have to have multiple clones.

In SQLite development, we *very* often have multiple branches and/or
historical versions of SQLite open and under development
simultaneously, and so having the ability to host these multiple
check-outs from a single repository is important.

>
> Pleasant surprises:
>
>- when making a branch, having a 'where from' basis (which I hope is
>retained)
>
> Questions:
>
>1. How do I choose a non 'trunk' name for the initial branch? My test
>needed a branch called 'one' and another 'two'.

You can change the branch to which any check-in belongs
after-the-fact.  Simple bring up the ui ("fossil ui") and click on the
link for the check-in, then on the "Edit" link.  Then use the "Make
this check-in the start of a new branch named: __" option.  This
can also be done from the command-line, though I cannot tell you how
off the top of my head - I'd have to go look

>2. Is it possible to do the --record-only merge thing subversion does
>(Git calls it ‘strategy-ours’, and in Perforce it is ‘accept yours’) ?

I'm not familiar with that feature.  What does it do?  Does it pretend
that one branch has been merged with other without actually changing
any of the code?  I don't recall ever having had a need for such a
thing?  Can you suggest a scenario where it might be useful?


>3. Where does Fossil top out? Nvidia, Pixar and Google pushed Perforce
>to multi-terrabytes of HEAD revision, metadate and history. With
>submodules, git doesn't like to be able 1GB (size of clone), though some
>field reports suggest 7GB works too.
>

SQLite database files top out at around 140 Terabytes.  There are,
however, some operations that use time proportional to the size of the
database.  "clone" and "rebuild" come quickly to mind.

Performance problems come about more due to the number of files in a
single check-out.  Most projects have a few thousand source files, for
which Fossil works great.  When the number of files in a single
revision gets into the hundreds of thousands, then some operations can
become sluggish.  This could perhaps be fixed, except I do not have
any such projects and so have not taken the time to work on it.

-- 
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

[fossil-users] Merge tracking tests in a blog entry, some questions

[Paul Hammant]

Hi there.

I did a blog entry on Fossil, and how it is able to handle a cherry-pick
merge scenario that breaks subversion:
http://paulhammant.com/2016/06/18/subversion-merge-limitations-not-in-fossil/

Learning curve for Fossil - about an hour.  Curiosities:

   - Having a database name rather than just a .git or .svn folder
   convention
   - The 'open' step.

Pleasant surprises:

   - when making a branch, having a 'where from' basis (which I hope is
   retained)

Questions:

   1. How do I choose a non 'trunk' name for the initial branch? My test
   needed a branch called 'one' and another 'two'.
   2. Is it possible to do the --record-only merge thing subversion does
   (Git calls it ‘strategy-ours’, and in Perforce it is ‘accept yours’) ?
   3. Where does Fossil top out? Nvidia, Pixar and Google pushed Perforce
   to multi-terrabytes of HEAD revision, metadate and history. With
   submodules, git doesn't like to be able 1GB (size of clone), though some
   field reports suggest 7GB works too.

 - Paul
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users