> > - 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
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
