P.S. On convenience. Cloning into single directory and setting up single project makes it works just as well. Decent IDEs handle this easily.
On tracking history. The need to track history of experimental code obfuscates its poor documentation. If the code if properly documented (including documenting design decisions), there is no need to search history. Moreover, if experimental code changed approach or algorithm radically (with reasons that should be documented), the history might confuse more than clarify. Modulo tracking history, multiple modular repos are more flexible than one jumbo repo. On 19 August 2016 at 18:01, Aliaksandr Autayeu <aliaksa...@autayeu.com> wrote: > Separating site and code is not enough. Different code requires different > levels of maintenance, that's why it's better to separate sandbox and > add-ons from trunk too. Sandbox might become outdated or might not compile. > It might have a different test or code coverage criteria. It might allow > warnings on compilation. Such things tends to spread from > unstable\experimental code to cleaner and more stable places. For example, > 1 warning stands out and therefore is more likely to be fixed. 5 warnings > from sandbox might easily cloud 6th one from trunk. > > On 19 August 2016 at 16:21, Richard Eckart de Castilho < > richard.eck...@gmail.com> wrote: > >> Keeping site and code in separate repos: +1 >> >> -- Richard >> >> > On 19.08.2016, at 15:17, Anthony Beylerian <anthony.beyler...@gmail.com> >> wrote: >> > >> > @Jörn @Richard >> > >> > I believe less bloat is always better for code housekeeping. >> > For example, although it is small, I think having the site code along >> with >> > the toolkit code just seems a bit untidy. >> > >> > How about we at least separate those two? >> > It could also be useful to make a more feature rich site in the future. >> > >> > Actually, the Spark team does that too: >> > >> > git://git.apache.org/spark.git >> > git://git.apache.org/spark-website.git >> >> >
