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
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 can't)
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
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?
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 when a
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 unless
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 to
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.txt.2,
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.
Hmm, what
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 work
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, especially with
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.
It
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 environment
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
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
this.
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 files
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
17 matches
Mail list logo
