Hello, On Tue, Aug 26, 2008 at 01:15:51PM +0200, Arne Babenhauserheide wrote: > Hi, > > This is just a general idea which struck me: > > With translators it would be easily possible to hide version tracking > activity > by just stacking a version tracking translator over some directory. > > A way to control that would then be, to have the translator create virtual > files for control. Something like > > repo_dir/ > .add/ > .commit > .pull > .push > .remove/ > .update > file1 > file2 > > # Add files > echo * > .add > > # commit > echo "Commit message" > .commit > > # update to some revision > echo 123 > .update > > Would easily be possible.
This is just a clumsier version of the original commands, even worse you won't get any meaningful error messages if the operation fails. > There wouldn't be any visible storage dir, since the directory would just be > shown as normal file dir with some extra non-standard files. Yes, but how would multiple non-standard files better than a single storage dir? > Can a translator change how cp works, so that copying such a dir would clone > the repo and layer a new translator upon the target (if the target is on a > Hurd)? It's not possible for a translator to change programs using it, but you could change the program to treat it specially. Though I would not recommend changing cp, since that would be *very* confusing, if it were suddenly to change behaviour in certain cases. > Thanks for reading the strange idea until the end. > > I hope you enjoyed it. :) I enjoyed shooting it down. ;-) Seriously though, it did get me thinking how useful version control translators might look like. The key here is not to try to replace the command set with a filesystem equivalent, but to supplement it. It would be very nice if you could set up a translator that showed every revision in a seperate directory. Making it almost trivial to browse a projects history and compare different revisions. Perhaps even allowing edits to sanitize history of a personal repo before a major commit to a public repo. Another possibility would be a versioning filesystem, were changes to files are recorded. This wouldn't be useful as a repo, since there are no logs and effects are immediate. But it would be nice to be able to undo recent changes. Regards, Fredrik
