Talk:Develop

see also Talk:Old Develop activity.

Journal resume, tabbed editing.

Response to [1], copied here:

Adding tabbed editing has made me rethink how Develop works. Before, when you hit Keep, Develop saved the activity with a copy of the file that you were editing. This way you could come back to an older version. With tabbed editing, my plan now is:

• each file (eventually, only each changed file) gets an object in the datastore.
• when we keep, we keep each of the individual files that's opened, and then store the object ids
• if we want to go back in time, we can resume either an individual file or the whole activity at that time

This means Develop needs to support being resumed with a file or a saved Develop activity. Eventually, it should also support being resumed with an Activity, to start development on that.

I think that for now, keep should bundle up the whole activity. It should automatically do a keep when first started on an activity. When restarted with a bundle, it should check that there is an older bundle of the same activity. If there is, it should overwrite the activity in the unbundled directory structure; if not, it should do a "copy of"-type renaming. To export individual files for editing, there should be another button, not "keep". Homunq 12:43, 5 February 2008 (EST)

Right now, keep just saves all the files. I like the idea of Keep bundling the Activity into an .xo file; but then what happens when we resume? We're no longer talking about a directory on the disk, but a single file. Paulswartz 01:25, 6 February 2008 (EST)

As I said, I think that it should check if there's something to "go back" to. If there is, it should overwrite. If not, it should make a new directory called "copy of ..." or some such. I know, that feels bad for duplicated storage and for dangerous overwriting, but I think it is not as bad as it seems. The current state and future plans for the journal should mitigate or remove both of these problems, I hope.

One thing that this makes me wonder, though, is the logic of having the xo file be compressed with zip. If jffs compresses anyway, there's no win; and the loss is that any future incremental-diff smarts in the journal are just out. But I guess we can cross that bridge, make the format also accept tar or something, if we come to it. Homunq 12:20, 6 February 2008 (EST)