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

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

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

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

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