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 _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
