Nicolas Williams wrote:
On Thu, Oct 05, 2006 at 05:25:17PM -0700, David Dyer-Bennet wrote:
No, any sane VC protocol must specifically forbid the checkin of the
stuff I want versioning (or file copies or whatever) for. It's
partial changes, probably doesn't compile, nearly certainly doesn't
w
On Fri, Oct 06, 2006 at 07:37:47PM -0600, Chad Leigh -- Shire.Net LLC wrote:
> On Oct 6, 2006, at 7:33 PM, Erik Trimble wrote:
> >This is what Nico and I are talking about: if you turn on file
> >versioning automatically (even for just a directory, and not a
> >whole filesystem), the number of
On Fri, Oct 06, 2006 at 06:33:14PM -0700, Erik Trimble wrote:
> But, because of the explosion in the number of files, you CAN'T
> automatically show all versions. Users will NEVER accept this. The only
> clean way to do this is to show file versions only upon request. Not by
> default.
Besides,
On Fri, Oct 06, 2006 at 05:11:54PM -0700, David Dyer-Bennet wrote:
> I don't recall that on TOPS-20 it was possible to not version. What
> you could do is set your logout.cmd file to purge your space down to
> one copy when you logged out.
I never used TOPS-20. I did use VMS. As I recall it did
On Sun, Oct 08, 2006 at 03:38:54PM -0700, Erik Trimble wrote:
> Joseph Mocker wrote:
> >Which brings me back to the point of file versioning. If an
> >implementation were based on something like when a file is open()ed
> >with write bits set. There would be no potential for broken files like
> >
On Sun, Oct 08, 2006 at 11:16:21PM -0400, Jonathan Edwards wrote:
> On Oct 8, 2006, at 22:46, Nicolas Williams wrote:
> >You're arguing for treating FV as extended/named attributes :)
>
> kind of - but one of the problems with EAs is the increase/bloat in
> the inode/dnode structures and corresp
On Oct 8, 2006, at 22:46, Nicolas Williams wrote:
On Sun, Oct 08, 2006 at 10:28:06PM -0400, Jonathan Edwards wrote:
On Oct 8, 2006, at 21:40, Wee Yeh Tan wrote:
On 10/7/06, Ben Gollmer <[EMAIL PROTECTED]> wrote:
Hmm, what about file.txt -> ._file.txt.1, ._file.txt.2, etc? If you
don't like t
On 10/9/06, Jonathan Edwards <[EMAIL PROTECTED]> wrote:
> We want to differentiate files that are created intentionally from
> those that are just versions. If files starts showing up on their
> own, a lot of my scripts will break. Still, an FV-aware
> shell/program/API can accept an environmen
On Sun, Oct 08, 2006 at 10:28:06PM -0400, Jonathan Edwards wrote:
> On Oct 8, 2006, at 21:40, Wee Yeh Tan wrote:
> >On 10/7/06, Ben Gollmer <[EMAIL PROTECTED]> wrote:
> >>Hmm, what about file.txt -> ._file.txt.1, ._file.txt.2, etc? If you
> >>don't like the _ you could use @ or some other character
On Mon, Oct 09, 2006 at 09:27:14AM +0800, Wee Yeh Tan wrote:
> On 10/7/06, David Dyer-Bennet <[EMAIL PROTECTED]> wrote:
> >I've never encountered branch being used that way, anywhere. It's
> >used for things like developing release 2.0 while still supporting 1.5
> >and 1.6.
> >
> >However, especia
On Thu, Oct 05, 2006 at 05:25:17PM -0700, David Dyer-Bennet wrote:
> No, any sane VC protocol must specifically forbid the checkin of the
> stuff I want versioning (or file copies or whatever) for. It's
> partial changes, probably doesn't compile, nearly certainly doesn't
> work. This level of wo
On Oct 8, 2006, at 21:40, Wee Yeh Tan wrote:
On 10/7/06, Ben Gollmer <[EMAIL PROTECTED]> wrote:
On Oct 6, 2006, at 6:15 PM, Nicolas Williams wrote:
> What I'm saying is that I'd like to be able to keep multiple
> versions of
> my files without "echo *" or "ls" showing them to me by default.
H
On 10/7/06, Ben Gollmer <[EMAIL PROTECTED]> wrote:
On Oct 6, 2006, at 6:15 PM, Nicolas Williams wrote:
> What I'm saying is that I'd like to be able to keep multiple
> versions of
> my files without "echo *" or "ls" showing them to me by default.
Hmm, what about file.txt -> ._file.txt.1, ._file.
On 10/7/06, David Dyer-Bennet <[EMAIL PROTECTED]> wrote:
I've never encountered branch being used that way, anywhere. It's
used for things like developing release 2.0 while still supporting 1.5
and 1.6.
However, especially with merge in svn it might be feasible to use a
branch that way. What's
On Sat, Oct 07, 2006 at 01:43:29PM +0200, Joerg Schilling wrote:
> The only idea I get thast matches this criteria is to have the versions
> in the extended attribute name space.
Indeed. All that's needed then, CLI UI-wise, beyond what we have now is
a way to rename versions extended attributes t
Joerg Schilling wrote:
Erik Trimble <[EMAIL PROTECTED]> wrote:
In order for an FV implementation to be useful for this stated purpose,
it must fulfill the following requirements:
(1) Clean interface for users. That is, one must NOT be presented with
a complete list of all versions unles
Joseph Mocker wrote:
Which brings me back to the point of file versioning. If an
implementation were based on something like when a file is open()ed
with write bits set. There would be no potential for broken files like
this.
Also, it would seem that your statement about snapshots as being "w
How do I do that?
I have the system messages (recorded by syslogd) and from there; you can kind
of tell roughly the time period as to when things went wrong.
If anybody from anywhere (Sun, ZFS, Solaris, etc.) wants to take a look at the
unix.* and vmcore.* data; in addition to any logs or syste
On Fri, Oct 06, 2006 at 06:22:01PM -0700, Joseph Mocker wrote:
> Nicolas Williams wrote:
> >Automatically capturing file versions isn't possible in the general case
> >with applications that aren't aware of FV.
> >
> Don't snapshots have the same problem. A snapshot could potentially be
> taken wh
On Fri, Oct 06, 2006 at 06:17:12PM -0700, Joseph Mocker wrote:
> David Dyer-Bennet's post gives a hint of how this could be done without
> any API. Simply augment a few system calls like open(), unlink(), etc.
> Calls that can potentially change files. Since you can't change a file
> unless is o
The scan order won't make any difference to ZFS, as it identifies the drives by
a label written to them, rather than by their controller path.
Perhaps someone in ZFS support could analyze the panic to determine the cause,
or look at the disk labels; have you made the core file available to Sun?
> I'm showing my lack of knowledge on this one but I thought SAM-FS could
> do something like this. Anyone know for sure?
It's not quite the same, and not out-of-the-box.
SAM-FS has the ability to create an archive copy of files onto disk or tape
when the files are closed after having been modi
David Dyer-Bennet wrote:
>
> Actually, "save early and often" is exactly why versioning is
> important. If you discover you've gone down a blind alley in some
> code, it makes it easy to get back to the earlier spots. This, in my
> experience, happens at a detail level where you won't (in fact c
P.S. I don't know if it makes any difference, but I did find that the scan
order has changed somewhat.
For example, right now, it starts the scan for the drives from sd10 (i.e.
[EMAIL PROTECTED],0) whereas before; the drive scan started with sd1 (i.e.
[EMAIL PROTECTED],0).
Would it make a diff
24 matches
Mail list logo
