OK - good points all round! Here are my use cases:
1. Incremental backup of all code - aka Apples Leopard's Time Machine 2. Shared code libraries - text only versioned and integrated into editing environment 3. Shared "MVC controllers" - same as above 4. Perhaps also a shared scrap book - documentation, code snippets, html and so forth. I agree with Richards pros and cons with regard Rev development - we agreed to disagree on this back when I wanted to host the MC IDE project on sourceforge. For development projects careful chinking of code into stacks with responsible developers is all that is needed. It is precisely Revs strengths at RAD development that make code versioning unecessary, and of little interest to companies focussed on RAD development of projects. However, IMO it is precisely this advantage which leads to the fact that there are very few high quality shared code libraries for Rev. At least it is one of the contributing factors. This is not a concern to an individual developer - it is quicker to roll your own in the short term - but is SHOULD be a concern to RunRev and the community, because over time our code base is inevitably out-competed by open source projects with large robust well tested freely available libraries. IMO code versioning is not the answer it is a factor towards a solution which can combine the best of both worlds. To go back to the use-cases: Incremental backup of all code - I've been using autobackup in Constellation for a while - but it backs up the whole stack in a seperate file every few minutes! multiply that by 50 or so stacks each with 10 or so versions and well... a lot of storage. How about the "binary problem"? As most of the work involved in the early stages is code, this can be automatically saves as a text file with hyperlinked documentation. as it is good practice to pull in images and templates as external files in any case (at least for development) - these can be versioned as well (not done yet). What do you get? Well the ability to go back to any stage of your project - you know the time when things were actually working before all those clever changes in 15 different stacks really screwed things up :) Shared "Code libraries" and "MVC controllers": both again text files only. The imporatnt part is shared and shared over time - which means a few developers working on them, and that these developers are likely to drop in and drop out over time - this sort of thing is what cvs / svn is good at manageing - organised chaos. The shared scrap book is probably best doen with a simple wiki. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
