Host the OpenSource components made available by the Synopse company. mORMot Framework Client-Server Delphi ORM (SQlite3 Oracle MSSQL OleDB ODBC) and interface based Services (like WCF): database access, User Interface generation, security, i18n and reporting are handled in a safe and fast SOA AJAX JSON RESTful model. PDF Engine is an Open Source PDF document creation library for Delphi, embedded in one unit. Use a true TCanvas to create the PDF, and embed True Type fonts subsets. Unicode ready. GDI+ SynGdiPlus unit: some TGraphic descendants are registered in your application to load and save GIF, TIF, PNG and JPG pictures. It also allows antialiased drawing from any TMetaFile.Read More →
This page lists a few projects that I've cloned from elsewhere.
Some of them still sync with the original repository, and in some cases I keep a local (private) branch with my own tweaks and additions.
The file ~/Library/Preferences/com.fuel-scm.Fuel.plist stores the value for Key Remotes.xxxx.Url incorrectly under Mac OS if you set a username + password for the remote repo. I am using Fuel 2.0 (the binary from the website) under Mac OS 10.12.6 (16G1618). (Thanks for the very useful program!)
It sets the URL to the value "@Variant(" (without the quotes).
I looked through the source code and suspect something odd with src/Utils.cpp, UrlToStringNoCredentials ??? This is just a guess as I have not debugged it.
With the same input under Windows (using Fuel 2.0 EXE), the program performs fine.
I have attempted to edit the .plist manually (using the form http://username:firstname.lastname@example.org/) but it reverts it to @Variant on startup.
It is still possible to manually edit it for the duration of Fuel running but it's annoying to have to set this every time, particularly if autosync is enabled.
The second point sounds good, but doing that will probably not allow us to remove as many commands as you'd think due to the -R flag.
For example, a fossil conf sync skin command will fail if you're not in a checkout directory, but you can add -R /path/to/repo.fossil to tell it which repo's skin you want synchronized.
The trick here is how do you know what a "sane" time value is, if the local clock is desynchronized?
The best idea I've got at the moment is that the Fossil configure script can look at time stamps or fossil stat info to find the newest timestamp on any file in the source tree, then consider that a minimum sane date for new content.
In production, this will put a floor on sanity down in the weeks to months range, so it would catch the 2002 problem brought up above, but it won't catch a problem where one client is only minutes to hours off of correct.
We've got to be somewhat careful here. For instance, if I turn off autosync while I'm off on a 2-week vacation, then make a few checkins on my portable machine while my relatives go do unimaginably weird things like visit the beach instead of write new software, when I return to work and sync my changes up, the server is going to see checkins up to 2 weeks old. The server must not reject those simply because they were created "in the past."
In a DVCS, there's a limit on how strict the central server can be. If we cannot trust time sync in 2018, a whole lot of other things break, too. make breaks, for instance.