Re: Versioning File Systems?

[Thomas Zimmerman <thomas@zimres.net>]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]