You are not logged in.
Pages: 1
Received by email from Erick:
First of all, thanks a lot for your work in your components. I'm not using them yet, but they look impressive.
I have downloaded the source code and I'd like to help, so I have questions:1 - Have you considered using a popular source coding host like Github or BitBucket? Most developers are already familiar with these services and would be easier to get more help and more users to the components, since your current download process is very complex and a lot of users will give up before even getting the code. Putting the code in Github for instance would give it much more exposure. I could help with this move if you want.
2 - Can you provide me with a username and password so that I can push some code? I have never used fossil before, should I create a branch with my changes?
One thing that I could help is setting some search paths in the sample projects, because they don't compile when you first download them.
Thanks
Erick
1. Using Git over a public repository instead of fossil on a private server is a recurrent idea.
See http://synopse.info/forum/viewtopic.php?pid=2417#p2417
and http://synopse.info/forum/viewtopic.php?pid=4832#p4832
What is complicate with getting the code?
Less than 5 clicks to have a .zip of any revision.
Fossil is a distributed SCM, just like GIT, but lighter, and all integrated.
The Git model works best for large projects, like the Linux kernel for which Git was designed.
Fossil is designed for smaller and non-hierarchical teams where all developers are operating directly on the master branch, or at most a small number of well defined branches. The autosync mode of Fossil makes it easy for multiple developers to work on a single branch and maintain linear development on that branch and avoid needless forking and merging.
http://www.fossil-scm.org/xfer/doc/trun … v-git.wiki
In fact, we use a lot the autosync mode of fossil, against several computers and network.
Working with Git over a proxy is not easy AFAIK, whereas fossil is just transparent.
It requires to install software, whereas in fossil, everything is embedded within one single executable.
We do not use branching much by now, working in the trunk, adding features to the main branch. A parallel per-branch work would make better sense, but as the main/single committer, I did not find it mandatory.
github make git easy to work with, and supply additional tools like wiki and issue tracking (already included in fossil).
But you are not the master of your data any more.
2. I could provide you with a username and password, but before pushing any source code, we probably better need to discuss on the forums about the purpose of such code.
Most of the time, some patches (or even whole new units or features) are sent via email to me, then I review, refactor, optimize the code before integrating it to mORMot.
Then, I can assume there is no speed nor feature regression, and that coding style, API and documentation are coherent.
I did not set any search path in the sample project, because:
1. I did not want to put some IDE configuration files in the repository;
2. In the installation procedure (both SAD + readme.txt) it clearly states to put both Lib and Lib\SQlite3 folders in the search path.
mORMot is a code-based solution, no need to install components, so no need to have a dedicated installer I guess.
Uncompress, set the search path (globally or not), and that's it.
People not able to install it, with the provided documentation, won't probably be able to use it!
Our framework is like most other frameworks: we provide the source code and documentation, and you do what you want with it.
Thanks a lot for your interest!
Offline
Pages: 1