On 18-Apr 12:55, Kent Borg wrote:
[snip]
> I am envisioning a richer version of the file stage. Just as users
> currently decide when to check in a version and when to checkpoint
> versions, I am imagining that sort of decision would still be made,
> but there would be a lower level of granularity that could be looked
> at if desired. Big infrequent changes to a file would all be
> recorded, and frequent little changes would be subject to some
> heuristic. It doesn't make sense to record a file's state so often
> that it isn't even self-consistent. For example, recording all the
> changes over the course of the save of a big Star Office drawing would
> be silly, most would be intermediate and dependent on the changing
> epheneral internal state of Star Office. I don't know the details of
> a reasonable heuristic other than obvious things such as when a file
> of flushed or closed or not touched for some significant time.
Why not commit versions on sync and close. That would seem to carry the least
surprise for the user. When I sync a filesystem/dir that would seem like a time
to make sure any changes make it to disk. And when a file is closed you don't
expect any more changes to that file.
>
> > That would actually be pretty interesting because it might also allow you to
> > back out editor screwup ;-)
>
> Writing an editor to take advantage of such underlying features would
> be pretty interesting too, it could be integrated into undo/redo
> features.
>
> Navigating such an historical fabric turns into a really interesting
> user interface problem.
Why teach current tools anything about it at all? Make this a tool you run on
the filesystem. If you _need_ to see earlier versions, it far past time to be
hoping emacs did the right thing.
> > However, deducing change sets is more difficult.
>
> I think change sets for source code would still be based on versions
> declared by a human to be of some specific interest. But changes sets
> for a computer's configuration might be implicit in the running of rpm
> or chkconfig, or reboots of the system, or saved edits to
> configuration files. Etc.
>
> Certainly what I am envisioning would have immediate use in looking at
> changes to specific files, but would require more structure imposed to
> be useful a system configuration management tool or source code
> control system.
[snip MS vaperware envy]
Thomas
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:25 EST