All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Peter van Hardenberg <pvh@uvic.ca>
Cc: reiserfs-list@namesys.com, Yoanis Gil Delgado <fred@lab.matcom.uh.cu>
Subject: Re: Authoring a versioning plugin
Date: Fri, 13 Jan 2006 12:34:11 -0800	[thread overview]
Message-ID: <43C80EC3.7050003@namesys.com> (raw)
In-Reply-To: <200601121014.37940.pvh@uvic.ca>

Peter van Hardenberg wrote:

>Hi Yoanis, good to see you're still pursuing this.
>
>On January 11, 2006 02:59 pm, Yoanis Gil Delgado wrote:
>  
>
>>This are the intentions:
>>To write a versioning plugin that will allows the file system user to
>>easily revert the files under versioning to a some previous state.  The
>>plugin will allow to revert the file state, based on revisions number and
>>date modifications(and not sure about this one). There will be a special
>>pseudo file named "previous" that will return the previous version of the
>>file. The final result should allow to the the following actions:
>>
>>$ echo 1 > myfile.txt  (let's say we make this command at Wed Jan 11
>>16:53:55) $ echo 2 > myfile.txt  (let's say we make this command at Wed Jan
>>11 16:54:57) $ echo 3 >> myfile.txt (let's say we make this command at Wed
>>Jan 11 16:55:59)
>>
>>Suppose you want the latest version, then you type:
>>$ cat myfile/.../previous
>> Some other content
>>Or you want the n-th version, then you type:
>>$ cat myfile/.../1
>> Some content
>>$ cat myfile/.../2
>> Some other content
>>$ cat myfile/.../3
>>    
>>
>
>This is going to clutter the ... directory rather a lot. Instead of adding 
>more files into "...." (which, by the way, is completely obscure) I would 
>suggest you create a new pseudo directory.
>
>Perhaps:
>$ cat myfile/.^4/history/previous
>$ cat myfile/.^4/history/version/1
>still not quite right, but at least it contains a bit more information about 
>what the "1" refers to.
>  
>
Ok, lets use myfile/..../versions/1 etc.

>
>I imagine that attribute should be
>$ echo "1" > myfile.txt/..../plugins/versioning
>or
>$ echo "everywrite" > myfile.txt/..../plugins/versioning
>
>Unfortunately, my experience is that you cannot use "echo" to change the data 
>in the plugins/* pseudoplugins, even when it should be legal to do so. I just 
>had a little ruby script that looked roughly like this:
>
>f = open pseudofile;
>f.write('newplugin');
>f.close;
>
>Never had the time to figure out why that was necessary, but there it is. 
>(There is a comment on the plugin-wiki gotchas section.)
>  
>
If someone figures out why we can't do it but /proc can, or even fixes
it, it would be good.


  parent reply	other threads:[~2006-01-13 20:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-11 22:59 Authoring a versioning plugin Yoanis Gil Delgado
2006-01-12  4:09 ` Hans Reiser
2006-01-12  6:44   ` Hans Reiser
2006-01-12 16:33     ` Jonathan Briggs
2006-01-12 18:33       ` Bedros Hanounik
     [not found]         ` <200601121502.32227.fred@lab.matcom.uh.cu>
2006-01-12 20:08           ` Yoanis Gil Delgado
2006-01-12 21:48         ` David Masover
2006-01-12 22:43           ` Bedros Hanounik
     [not found]             ` <200601121856.00665.fred@lab.matcom.uh.cu>
2006-01-12 23:56               ` Yoanis Gil Delgado
2006-01-13 20:59                 ` Hans Reiser
2006-01-13 16:43             ` David Masover
     [not found]     ` <200601121434.54881.fred@lab.matcom.uh.cu>
2006-01-12 20:05       ` Yoanis Gil Delgado
2006-01-12 19:13         ` Mike Benoit
2006-01-12 18:14 ` Peter van Hardenberg
     [not found]   ` <200601121439.09483.fred@lab.matcom.uh.cu>
2006-01-12 20:06     ` Yoanis Gil Delgado
2006-01-12 21:58   ` David Masover
2006-01-13 20:34   ` Hans Reiser [this message]
2006-01-13 21:17     ` Toomas Laasik
2006-01-13 21:48       ` Hans Reiser
2006-01-14 11:56       ` Pierre Etchemaïté
2006-01-13 23:00     ` Jonathan Sailor
2006-01-14  9:07       ` Peter van Hardenberg
2006-01-14 17:28         ` David Masover
2006-01-14 22:23           ` Hans Reiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43C80EC3.7050003@namesys.com \
    --to=reiser@namesys.com \
    --cc=fred@lab.matcom.uh.cu \
    --cc=pvh@uvic.ca \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.