Nicolas Williams [EMAIL PROTECTED] wrote:
On Wed, Oct 11, 2006 at 08:24:13PM +0200, Joerg Schilling wrote:
Before we start defining the first offocial functionality for this Sun
feature,
we should define a mapping for Mac OS, FreeBSD and Linux. It may make
sense, to
define a sub
On Fri, Oct 13, 2006 at 11:03:51AM +0200, Joerg Schilling wrote:
Nicolas Williams [EMAIL PROTECTED] wrote:
On Wed, Oct 11, 2006 at 08:24:13PM +0200, Joerg Schilling wrote:
Before we start defining the first offocial functionality for this Sun
feature,
we should define a mapping for
Nicolas Williams [EMAIL PROTECTED] wrote:
On Mon, Oct 09, 2006 at 12:44:34PM +0200, Joerg Schilling wrote:
Nicolas Williams [EMAIL PROTECTED] wrote:
You're arguing for treating FV as extended/named attributes :)
I think that'd be the right thing to do, since we have tools that are
On Fri, Oct 06, 2006 at 11:57:36AM -0700, Matthew Ahrens wrote:
[EMAIL PROTECTED] wrote:
On Fri, Oct 06, 2006 at 01:14:23AM -0600, Chad Leigh -- Shire.Net LLC
wrote:
But I would dearly like to have a versioning capability.
Me too.
Example (real life scenario): there is a samba server for
On Fri, Oct 06, 2006 at 02:08:34PM -0700, Erik Trimble wrote:
Also, save-early-save-often results in a version explosion, as does
auto-save in the app. While this may indeed mean that you have all of
your changes around, figuring out which version has them can be
massively time-consuming.
Erik Trimble [EMAIL PROTECTED] wrote:
The only idea I get thast matches this criteria is to have the versions
in the extended attribute name space.
Jörg
Realistically speaking, that's my conclusion, if we want a nice clean,
well-designed solution. You need to hide the versioning
Nicolas Williams [EMAIL PROTECTED] wrote:
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
Nicolas Williams [EMAIL PROTECTED] wrote:
You're arguing for treating FV as extended/named attributes :)
I think that'd be the right thing to do, since we have tools that are
aware of those already. Of course, we're talking about somewhat magical
attributes, but I think that's fine (though,
Joseph Mocker wrote:
However would it be great if I could somehow easily FV a file I am
working on with some arbitrary (closed) application I am forced to use
without the application really knowing about it, and with little or no
actions I have to take to do so?
To paraphrase an old wive's
On Mon, Oct 09, 2006 at 12:44:34PM +0200, Joerg Schilling wrote:
Nicolas Williams [EMAIL PROTECTED] wrote:
You're arguing for treating FV as extended/named attributes :)
I think that'd be the right thing to do, since we have tools that are
aware of those already. Of course, we're
On Oct 8, 2006, at 23:54, Nicolas Williams wrote:
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
On 10/6/06, Erik Trimble [EMAIL PROTECTED] wrote:
David Dyer-Bennet wrote:
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
Maybe Erik would find it confusing. I know I would find it
_annoying_.
Then leave it set to 1 version
Per-directory? Per-filesystem?
Whatever. What's
On 10/7/06, Erik Trimble [EMAIL PROTECTED] wrote:
Chad Leigh -- Shire.Net LLC wrote:
Plus, the number of files being created under typical
modern systems is at least two (and probably three or four) orders
of magnitude greater. I've got 100,000 files under /usr in Solaris,
and
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)
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 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
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, etc? If you
don't like the _ you could use @ or
Chad Leigh -- Shire.Net LLC wrote:
Plus, the number of files being created under typical
modern systems is at least two (and probably three or four) orders
of magnitude greater. I've got 100,000 files under /usr in Solaris,
and almost 1,000 under my home directory.
wimp :-) I
Chad Leigh -- Shire.Net LLC wrote:
But see, that assumes you have a logout-type functionality to use.
Which indeed is possible for command-line usage, but then only in a
very limited way. During a typical session, I access almost 20
NFS-mounted directories. And anyone using autofs/automount
Jeremy Teo [EMAIL PROTECTED] wrote:
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic snapshots, but versioning gives
us
Nicolas Williams [EMAIL PROTECTED] wrote:
On Fri, Oct 06, 2006 at 12:02:16PM -0700, Matthew Ahrens wrote:
In my opinion, the marginal benefit of per-write(2) versions over
snapshots (which can be per-transaction, ie. every ~5 seconds) does not
outweigh the complexity of implementation
David Dyer-Bennet [EMAIL PROTECTED] wrote:
On 10/6/06, Erik Trimble [EMAIL PROTECTED] wrote:
First of all, let's agree that this discussion of File Versioning makes
no more reference to its usage as Version Control. That is, we aren't
going to talk about it being useful for source code,
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 explicitly asked for
I seem to remember that one could configure the max. number of versions VMS
would retain for you on a per-file basis - setting this to 1 would de facto
turn off versioning.
IFF versioning were implemented in ZFS, AND was made configurable on a
per-file basis (everything else wouldn't make any
On Fri, Oct 06, 2006 at 01:14:23AM -0600, Chad Leigh -- Shire.Net LLC wrote:
But I would dearly like to have a versioning capability.
Me too.
Example (real life scenario): there is a samba server for about 200
concurrent connected users. They keep mainly doc/xls files on the
server. From time
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic snapshots, but versioning gives
us immediacy.
So is immediacy worth it to you
On Fri, Oct 06, 2006 at 11:25:29PM +0800, Jeremy Teo wrote:
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic snapshots,
On Fri, Oct 06, 2006 at 09:40:22AM +0200, [EMAIL PROTECTED] wrote:
Example (real life scenario): there is a samba server for about 200
concurrent connected users. They keep mainly doc/xls files on the
server. From time to time they (somehow) currupt their files (they
share the files so it is
[EMAIL PROTECTED] wrote:
On Fri, Oct 06, 2006 at 01:14:23AM -0600, Chad Leigh -- Shire.Net LLC wrote:
But I would dearly like to have a versioning capability.
Me too.
Example (real life scenario): there is a samba server for about 200
concurrent connected users. They keep mainly doc/xls files
Jeremy Teo wrote:
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic snapshots, but versioning gives
us immediacy.
So is
Matthew Ahrens wrote:
If you disagree, please tell us *why* you think snapshots don't solve
the problem.
Technically there's a race condition here. If you're taking regular
snapshots, you might see
10:25 - snapshot 1 - myfile.xls version 21
10:26 -- myfile.xls version 22
On 10/6/06, Matthew Ahrens [EMAIL PROTECTED] wrote:
Jeremy Teo wrote:
A couple of use cases I was considering off hand:
1. Oops i truncated my file
2. Oops i saved over my file
3. Oops an app corrupted my file.
4. Oops i rm -rf the wrong directory.
All of which can be solved by periodic
Chad Leigh -- Shire.Net LLC wrote:
disclaimer: I have not used zfs snapshots a lot as I am still
experimenting with zfs, but they appear to be similar to freebsd
snapshots, with which I am familiar.
The user experience with snapshots, in terms of file versioning (#1,
#2, maybe #3) is
First of all, let's agree that this discussion of File Versioning makes
no more reference to its usage as Version Control. That is, we aren't
going to talk about it being useful for source code, other than in the
context where a source code file is a document, like any other text
document.
Chad Leigh -- Shire.Net LLC wrote:
disclaimer: I have not used zfs snapshots a lot as I am still
experimenting with zfs, but they appear to be similar to freebsd
snapshots, with which I am familiar.
The user experience with snapshots, in terms of file versioning (#1,
#2, maybe #3) is much
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
First of all, let's agree that this discussion of File Versioning
makes no more reference to its usage as Version Control. That is,
we aren't going to talk about it being useful for source code,
other than in the context where a source code
On 10/6/06, Erik Trimble [EMAIL PROTECTED] wrote:
First of all, let's agree that this discussion of File Versioning makes
no more reference to its usage as Version Control. That is, we aren't
going to talk about it being useful for source code, other than in the
context where a source code file
On Fri, Oct 06, 2006 at 03:30:20PM -0600, Chad Leigh -- Shire.Net LLC wrote:
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
OK. So, now we're on to FV. As Nico pointed out, FV is going to
need a new API. Using the VMS convention of simply creating file
names with a version string
On Oct 6, 2006, at 3:53 PM, Nicolas Williams wrote:
On Fri, Oct 06, 2006 at 03:30:20PM -0600, Chad Leigh -- Shire.Net
LLC wrote:
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
OK. So, now we're on to FV. As Nico pointed out, FV is going to
need a new API. Using the VMS convention of
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
On Fri, Oct 06, 2006 at 03:30:20PM -0600, Chad Leigh -- Shire.Net LLC wrote:
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
OK. So, now we're on to FV. As Nico pointed out, FV is going to
need a new API. Using the VMS convention of
Chad,
I think our problem is that we look at FV from different angles. I look
at it from the point of view of people who have NEVER used FV, and you
look at it from the view of people who have ALWAYS used FV.
For those of us who have never had FV available, technical users have
used VC
On Fri, Oct 06, 2006 at 04:06:37PM -0600, Chad Leigh -- Shire.Net LLC wrote:
On Oct 6, 2006, at 3:53 PM, Nicolas Williams wrote:
On Fri, Oct 06, 2006 at 03:30:20PM -0600, Chad Leigh -- Shire.Net
LLC wrote:
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
OK. So, now we're on to FV. As Nico
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
On Fri, Oct 06, 2006 at 04:06:37PM -0600, Chad Leigh -- Shire.Net LLC wrote:
On Oct 6, 2006, at 3:53 PM, Nicolas Williams wrote:
Maybe Erik would find it confusing. I know I would find it
_annoying_.
Then leave it set to 1 version
Nicolas Williams wrote:
On Fri, Oct 06, 2006 at 03:30:20PM -0600, Chad Leigh -- Shire.Net LLC wrote:
On Oct 6, 2006, at 3:08 PM, Erik Trimble wrote:
OK. So, now we're on to FV. As Nico pointed out, FV is going to
need a new API. Using the VMS convention of simply creating file
Nicolas Williams wrote:
The big question though is: how to snapshot file versions when they are
touched/created by applications that are not aware of FV?
Certainly not with every write(2). At fsync(2), close(2), open(2) for
write/append? What if an application deals in multiple files?
David Dyer-Bennet wrote:
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
Maybe Erik would find it confusing. I know I would find it
_annoying_.
Then leave it set to 1 version
Per-directory? Per-filesystem?
Whatever. What's the actual issue here?
I don't recall that on TOPS-20
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 being created explodes
geometrically.
But it doesn't. Unless you are
Joseph Mocker wrote:
Nicolas Williams wrote:
The big question though is: how to snapshot file versions when they are
touched/created by applications that are not aware of FV?
Certainly not with every write(2). At fsync(2), close(2), open(2) for
write/append? What if an application deals in
On Oct 6, 2006, at 7:33 PM, Erik Trimble wrote:
David Dyer-Bennet wrote:
On 10/6/06, Nicolas Williams [EMAIL PROTECTED] wrote:
Maybe Erik would find it confusing. I know I would find it
_annoying_.
Then leave it set to 1 version
Per-directory? Per-filesystem?
Whatever. What's the
Erik Trimble wrote:
The problem is we are comparing apples to oranges in user bases here.
TOPS-20 systems had a couple of dozen users (or, at most, a few
hundred). VMS only slightly more. UNIX/POSIX systems have 10s of
thousands.
IIRC, I had about a dozen files under VMS, not counting
On Oct 6, 2006, at 10:18 PM, Richard Elling - PAE wrote:
Erik Trimble wrote:
The problem is we are comparing apples to oranges in user bases
here. TOPS-20 systems had a couple of dozen users (or, at most, a
few hundred). VMS only slightly more. UNIX/POSIX systems have
10s of thousands.
On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:
On 10/5/06, Jeremy Teo [EMAIL PROTECTED] wrote:
What would a version FS buy us that cron+ zfs snapshots doesn't?
Finer granularity; no chance of missing a change.
TOPS-20 did this, and it was *tremendously* useful .
Brian Hechinger wrote:
On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:
On 10/5/06, Jeremy Teo [EMAIL PROTECTED] wrote:
What would a version FS buy us that cron+ zfs snapshots doesn't?
Finer granularity; no chance of missing a change.
TOPS-20 did this, and it was
Brian Hechinger wrote:
On Thu, Oct 05, 2006 at 11:19:19AM -0700, David Dyer-Bennet wrote:
On 10/5/06, Jeremy Teo [EMAIL PROTECTED] wrote:
What would a version FS buy us that cron+ zfs snapshots doesn't?
Finer granularity; no chance of missing a change.
TOPS-20 did this, and it was
On 10/5/06, Erik Trimble [EMAIL PROTECTED] wrote:
Doing versioning at the file-system layer allows block-level changes to
be stored, so it doesn't consume enormous amounts of extra space. In
fact, it's more efficient than any versioning software (CVS, SVN,
teamware, etc) for storing versions.
On Thu, Oct 05, 2006 at 04:08:13PM -0700, David Dyer-Bennet wrote:
when you do your session-end cleanup. What the heck was that command
on TOPS-20 anyway? Maybe purge? Sorry, 20-year-old memories are
fuzzy on some details.
It's PURGE under VMS, so knowing DEC, it was named PURGE under
On Thu, 2006-10-05 at 16:08 -0700, David Dyer-Bennet wrote:
On 10/5/06, Erik Trimble [EMAIL PROTECTED] wrote:
Doing versioning at the file-system layer allows block-level changes to
be stored, so it doesn't consume enormous amounts of extra space. In
fact, it's more efficient than any
A lot of this we're clearly not going to agree on and I've said what I
had to contribute. There's one remaining point, though...
On 10/5/06, Erik Trimble [EMAIL PROTECTED] wrote:
On Thu, 2006-10-05 at 16:08 -0700, David Dyer-Bennet wrote:
Actually, save early and often is exactly why
On Thu, 2006-10-05 at 17:25 -0700, David Dyer-Bennet wrote:
Well, unless you have a better VCS than CVS or SVN. I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was called NSE, the Network Software Engineering
environment. And I used one
On 10/6/06, David Dyer-Bennet [EMAIL PROTECTED] wrote:
One of the big problems with CVS and SVN and Microsoft SourceSafe is
that you don't have the benefits of version control most of the time,
because all commits are *public*.
David,
That is exactly what branch is for in CVS and SVN. Dunno
On October 5, 2006 5:25:17 PM -0700 David Dyer-Bennet [EMAIL PROTECTED] wrote:
Well, unless you have a better VCS than CVS or SVN. I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was called NSE, the Network Software Engineering
environment. And
On Oct 5, 2006, at 7:47 PM, Chad Leigh -- Shire.Net LLC wrote:
I find the unix conventions of storying a file and file~ or any
of the other myriad billion ways of doing it that each app has
invented to be much more unwieldy.
sorry, storing a file, not storying
---
Chad Leigh --
On Oct 5, 2006, at 6:48 PM, Frank Cusack wrote:
On October 5, 2006 5:25:17 PM -0700 David Dyer-Bennet [EMAIL PROTECTED]
b.net wrote:
Well, unless you have a better VCS than CVS or SVN. I first met this
as an obscure, buggy, expensive, short-lived SUN product, actually; I
believe it was
On October 5, 2006 7:02:29 PM -0700 Chad Lewis [EMAIL PROTECTED] wrote:
On Oct 5, 2006, at 6:48 PM, Frank Cusack wrote:
On October 5, 2006 5:25:17 PM -0700 David Dyer-Bennet [EMAIL PROTECTED]
b.net wrote:
Well, unless you have a better VCS than CVS or SVN. I first met this
as an obscure,
74 matches
Mail list logo
