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

2016-06-19 Thread Paul Hammant 
> >- 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.
>

Super cool feature, I agree.


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

Yes, that's nice. Specifically, workspace (optionally) *not* 1:1 with
clone.

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

I can live without know the command line fu for that, for the sake of a
blog series.  Might be nice as a low priority feature request for 'init':

fossil init .fossilDB --default-branchname one


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

There are plenty of useful scenarios, but the biggest is 'maintained
divergence' - http://paulhammant.com/2013/04/02/maintained-divergence/.
That, and three years ago I made a config system with a colleague resting
on SCM for production use (as opposed to developer use) -
https://github.com/paul-hammant/app-config-app that it would be nice to
return to.

>3. Where does Fossil top out?
>
>>
> 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.
>

Impressive.


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

That's my use case, too.

Note, Git and Subversion) have 'sparse-checkouts', but not 'sparse clones'.
Perforce's git-fusion adapter can do sparse clones (kindof a holy-grail).
You think you've cloned the whole repo, say, but perforce silently masked
out a set of directories (not necessarily at root).  Perforce had
fine-grained R+W permissions for that, as well as client-spec globbing that
Google used to the nth degree -
http://paulhammant.com/2014/01/06/googlers-subset-their-trunk/  Note,
Google replaced Perforce as their backend (their one big trunk) in 2012
with some in-house perforce-alike thing, but I did not know at the time of
writing the above article.

In terms of build systems - Facebook's Buck and Google's Bazel are in the
image of Google's internal Blaze, and that had the ability to deliberately
manipulate 'sparse checkout' settings.

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

2016-06-19 Thread Paul Hammant 
Nice writeup Ron.  Worth putting up online for posterity (I mean a page
with a URL rather than left in web-mail).  It certainly provides some
additional nuggets of information to the #1 ranked quick start :)

I have a small lament. Specifically that casual users can't (optionally)
clone and make working-copy in one go.

$ fossil clone --quiet --working-copy-too --replica-in-dotfile-please
http://www2.fossil-scm.org/  fossils_own_source
$ cd fossils_own_source
$ ls -al .fossil
-rw-r--r--  1 paul  staff  38551552 Jun 19 08:50 fossilRepo.fossil


Indeed I seem to have gotten myself in a mess with Fossil's (v1.34) own
checkout:

$ mkdir playing_with_fossil
$ cd !$
cd playing_with_fossil
$ pwd
/scm/oss/playing_with_fossil
$ fossil clone http://www2.fossil-scm.org/ fossilRepo.fossil
Round-trips: 7   Artifacts sent: 0  received: 33878
Clone done, sent: 1688  received: 33007963  ip: 66.228.42.154
Rebuilding repository meta-data...
  100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
server-id:  8b598a187666c8c1d32e6ad19cefd11e2cf19a20
admin-user: paul (password is "e7e2c6")
$ ls -al fossilRepo.fossil
-rw-r--r--  1 paul  staff  38551552 Jun 19 08:52 fossilRepo.fossil
$ mkdir wc
$ cd wc
$ fossil checkout ../fossilRepo.fossil
Fossil internal error: repository does not exist or is in an unreadable
directory: /scm/oss/fossilsOwnRepo

That last directory or file - /scm/oss/fossilsOwnRepo - I deleted that
yesterday. I don't know why attempts to checkout are referring to it.  Is
there something in ~/.fossil that's residual about local repos / replicas
and affects all open shells going forward?

Guidance appreciated.

- Paul


On Sun, Jun 19, 2016 at 4:39 AM, Ron W  wrote:

> On Sat, Jun 18, 2016 at 1:21 PM, Paul Hammant  wrote:
>
>> Curiosities:
>>
>>- Having a database name rather than just a .git or .svn folder
>>convention
>>- The 'open' step.
>>
>> Fossil and SVN are more similar than you seem to think.
>
> Fossil's "open" command is much like SVN's "checkout" command. Both take a
> path to a repository. The difference being that Fossil expects a local
> database file while SVN expects an URL to the repository, which SVN treats
> as remote, even if it is local. This is because SVN clients all work from a
> central repo, while Fossil works with a local repo that might be a copy of
> a remote/central repo. And, like SVN's "checkout" command, "open" also
> checks out files into your working copy.
>
> Also, like SVN, when a working copy is created, a .fossil file is created
> in the base folder of the working copy. (SVN uses a folder, Fossil uses a
> database file.)
>
> Fossil's "update" is pretty much the same as SVN's "update".
>
> Fossil's "checkout" is a bit different. While it fetches the specified
> version of files, it does not attempt to merge with local changes.
>
> So, like SVN, Fossil allows multiple working copies from the same repo.
> But Fossil working copies are associated with a local repo while SVN
> working copies are associated with a remote/central repo.
>
> The local Fossil repo is what might be associated with a remote/central
> repo. A pull, push or sync command done from any of the working copies will
> cause the associate repo to interact with the remote repo. SVN commands
> always interact directly with the remote repo, so SVN doesn't have pull,
> push or sync.
>
> Also, when you commit from one local working copy, you can then update
> from another local working copy without doing a pull, push or sync. Remote
> working copies won't be able to update to your commit until pull, push or
> sync (as appropriate) is done to get the commit transferred.
>
> git, on the other hand, every working copy has it's own local copy of the
> repo, so each local working copy is completely independent, just as a
> remote working copy would be. To transfer commits between git working
> copies - local or remote - you have to pull, push or sync.
>
> From my point of view, Fossil provides the best of a DVCS with the best
> features of SVN or other non distributed VCS. I can perform VCS operations
> "off line", even with multiple working copies (with only one local copy of
> the repo), then still be able to easily sync to a remote repo once online.
>
>
> ___
> 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

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

2016-06-19 Thread Ron W 
On Sat, Jun 18, 2016 at 1:21 PM, Paul Hammant  wrote:

> Curiosities:
>
>- Having a database name rather than just a .git or .svn folder
>convention
>- The 'open' step.
>
> Fossil and SVN are more similar than you seem to think.

Fossil's "open" command is much like SVN's "checkout" command. Both take a
path to a repository. The difference being that Fossil expects a local
database file while SVN expects an URL to the repository, which SVN treats
as remote, even if it is local. This is because SVN clients all work from a
central repo, while Fossil works with a local repo that might be a copy of
a remote/central repo. And, like SVN's "checkout" command, "open" also
checks out files into your working copy.

Also, like SVN, when a working copy is created, a .fossil file is created
in the base folder of the working copy. (SVN uses a folder, Fossil uses a
database file.)

Fossil's "update" is pretty much the same as SVN's "update".

Fossil's "checkout" is a bit different. While it fetches the specified
version of files, it does not attempt to merge with local changes.

So, like SVN, Fossil allows multiple working copies from the same repo. But
Fossil working copies are associated with a local repo while SVN working
copies are associated with a remote/central repo.

The local Fossil repo is what might be associated with a remote/central
repo. A pull, push or sync command done from any of the working copies will
cause the associate repo to interact with the remote repo. SVN commands
always interact directly with the remote repo, so SVN doesn't have pull,
push or sync.

Also, when you commit from one local working copy, you can then update from
another local working copy without doing a pull, push or sync. Remote
working copies won't be able to update to your commit until pull, push or
sync (as appropriate) is done to get the commit transferred.

git, on the other hand, every working copy has it's own local copy of the
repo, so each local working copy is completely independent, just as a
remote working copy would be. To transfer commits between git working
copies - local or remote - you have to pull, push or sync.

>From my point of view, Fossil provides the best of a DVCS with the best
features of SVN or other non distributed VCS. I can perform VCS operations
"off line", even with multiple working copies (with only one local copy of
the repo), then still be able to easily sync to a remote repo once online.
___
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

2016-06-18 Thread 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

2016-06-18 Thread 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

2016-06-18 Thread 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