From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: Versioning Plugin Date: Sat, 12 Nov 2005 14:54:01 -0800 Message-ID: <43767289.1000402@namesys.com> References: <200511111359.39715.jgilmore@glycou.com> <200511111656.04891.pvh@uvic.ca> <1131804415.8550.14.camel@localhost.localdomain> <437662CC.9010307@slaphack.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <437662CC.9010307@slaphack.com> List-Id: Content-Type: text/plain; charset="us-ascii" To: David Masover Cc: mingz@ele.uri.edu, Peter van Hardenberg , reiserfs-list@namesys.com David Masover wrote: >Ming Zhang wrote: > > >>On Fri, 2005-11-11 at 16:56 -0800, Peter van Hardenberg wrote: >> >> >> >>>On November 11, 2005 05:59 am, John Gilmore wrote: >>> >>> >>> >>>>Does anybody remember GoBack? It was a versioning >>>>system for windows 95/98 that was incredibly flexible and useful. Tracked >>>>all changes to the whole disk. Old versions of a file? no problem. grab an >>>>old version of a directory for referance temporarily? easy. Got a virus? >>>>revert the whole HD, and then grab the newer copies of your documents and >>>>saved games as needed. >>>> >>>> >>>My thoughts on this: >>> >>>The versioning would be an audit plugin. When the file is modified, tag the >>>current version, copy it into a sub-directory (oh, I don't know, say >>>file/.revisions/), and disable write access to it. You might not >>>even need extended filesystem attributes for this, but they would be handy >>>for tagging particular versions. >>> >>> >>if a file is opened, modified 2 times, then closed. u will only generate >>1 version right? so "When the file is modified" is inaccurate. >> >> one could do it for every file close, and that could be a state option for the versioning plugin, but most users will want to do it everytime they touch filename/..../checkin > >How about "When the transaction was completed?" Why does it matter? > > > >>>Copy-on-write would make this action extremely cheap, only adding a couple of >>>extra writes to make it work. >>> >>> >>add 1 line at the beginning of a 100MB text file will make this uncheap. >> >> > >Who has to work with 100 meg text files? And why has this person not >broken them down into 100 kilobyte text files? Storage efficiency isn't >really an issue there... > > you need cross-version compression for this case. >Anyway, I think the main win is from copy-on-write for the whole file. > > > > >