On Feb 7, 2008, at 4:20 PM, Mathieu Bouchard wrote:
On Thu, 7 Feb 2008, Hans-Christoph Steiner wrote:
When looking at a file, say pd/src/s_file.c, then there are be dd- specific commits in the history, that's what I mean.
That's been mostly over for a while. Most changes in DesireData in the past year were in merged files with a new name... for example, m_*.c became a new file named kernel.c. Most d_*.c are now builtins_dsp.c, most x_*.c are now builtins.c, etc. Just like desire.c was g_*.c since mid-2005. Some files are still not renamed nor merged, mostly s_*.c.
This is a good example of why dd shouldn't be a branch of pd. If you are introducing new files that are never intended to be included in pd/src, then it just gets messy having those extra non-pd files in the repository while providing no benefit that I can think of.
Many repositories have scripted commit policies that check all sorts of things before allowing a commit, things like it needs to compile, it needs not use deprecate libraries, etc. etc.
Well, neither the PureData nor the DesireData projects have that, and I don't think I've ever heard such scripts being discussed on the pd-dev mailing-list. So, why would it be an issue now?
It has been discussed in the past. But I was saying more that you would be free to implement your own such policies if you used your own repository.
I really don't see any real advantage to keeping dd in the pure-data repository.
.hc
------------------------------------------------------------------------ ----
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin