Talk:Develop: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Dead? Interest?)
Line 26: Line 26:
== Dead? Interest? ==
== Dead? Interest? ==


No activity on [http://dev.laptop.org/git?p=activities/develop;a=summary|the repository] on this activity for a while... what is the consensus?
No activity on [http://dev.laptop.org/git?p=activities/develop;a=summary the repository] on this activity for a while... what is the consensus?


[[Develop]] incarnation #3? Start with [[Pippy]], and build/test features slowly?
[[Develop]] incarnation #3? Start with [[Pippy]], and build/test features slowly?

Revision as of 18:47, 18 June 2008

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)
We did a chat on this and thought a bit about the dangerous case when an activity is running and being edited and is resumed from the journal all at the same time. I think that there are solutions but it is tricky. Homunq 17:30, 6 February 2008 (EST)

Dead? Interest?

No activity on the repository on this activity for a while... what is the consensus?

Develop incarnation #3? Start with Pippy, and build/test features slowly?

--Bjordan 14:45, 18 June 2008 (EDT)