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

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

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

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

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

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

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

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

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

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

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