From: Hans Reiser <reiser@namesys.com>
To: Hans Reiser <reiser@namesys.com>,
Yoanis Gil Delgado <fred@lab.matcom.uh.cu>
Cc: reiserfs-List@namesys.com
Subject: Re: Authoring a versioning plugin
Date: Wed, 11 Jan 2006 22:44:48 -0800 [thread overview]
Message-ID: <43C5FAE0.5090602@namesys.com> (raw)
In-Reply-To: <43C5D694.9050402@namesys.com>
Hans Reiser wrote:
>:
>
>
>
> I am skeptical that having it occur with every
>write is desirable actually.
>
>
Consider the case where you type cat file1 >> file2. This will produce
a version of file2 for every 4k that is in file1, because (well I didn't
look at the bash source, but I would guess) it appends in 4k incremental
writes rather than one big write. Versioning on file close makes more
sense, but I suggest manual control using the ..../checkin pseudofile,
and then we can reasonably make it the default plugin for the whole FS
(write it so that it calls the other plugins so that when we change the
other plugins we don't need to change your code to do it). People who
don't want versioning will simply never touch the checkin pseudofile.
Make sure that for that case there is just an if statement condition
check as overhead, and there will be no reason to not make versioning
the default plugin that happens to do nothing unless you use the checkin
pseudofile at least once during the life of the file.
hmm, maybe ..../snap is better than ..../checkin ? Well, let's decide
that once the code is written....;-)
Do you agree with my points here?
Hans
next prev parent reply other threads:[~2006-01-12 6:44 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 [this message]
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
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=43C5FAE0.5090602@namesys.com \
--to=reiser@namesys.com \
--cc=fred@lab.matcom.uh.cu \
--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.