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
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
> > def
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 directory for the attribute directory for keepi
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 hav
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 Solar
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-filesyste
On Mon, Oct 09, 2006 at 11:16:41AM -0400, Jonathan Edwards wrote:
> On Oct 8, 2006, at 23:54, Nicolas Williams wrote:
> >Let's keep interface and implementation details separate. Most of
> >this
> >thread has been about interfaces precisely because that's what users
> >will interact with; users
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 increase/blo
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,
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
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 (t
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
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
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-consu
[EMAIL PROTECTED] wrote:
I completely disagree. In this scenario (and almost all others), use of
regular snapshots will solve the problem. 'zfs snapshot -r' is
extremely fast, and I'm working on some new features that will make
using snapshots for this even easier and better-performing.
If
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 samb
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 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
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
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
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
"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 so
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 implement
"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
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 t
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 co
Joseph Mocker wrote:
Erik Trimble wrote:
The developers can answer this definitively, but I believe the answer
to your questions is NO. That is, if there is anything in the buffer
waiting to be written when a snapshot request comes along, the buffer
is written out so that the file is consi
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 @
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.
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 ver
On Oct 6, 2006, at 21:17, Joseph Mocker wrote:
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 t
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
Erik Trimble wrote:
The developers can answer this definitively, but I believe the answer
to your questions is NO. That is, if there is anything in the buffer
waiting to be written when a snapshot request comes along, the buffer
is written out so that the file is consistent with the last wr
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:
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 ed
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 T
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? Etc..
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
nam
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 ve
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
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 tools
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 o
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 simpl
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 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 fil
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 Oct 6, 2006, at 3:14 PM, Erik Trimble wrote:
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 te
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 wo
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. Fi
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 m
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 and use/administration.
Per-write(2) versions
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 pe
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
10:27
On Oct 6, 2006, at 1:02 PM, Matthew Ahrens 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 snapshot
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 immedia
[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
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
On 10/5/06, Wee Yeh Tan <[EMAIL PROTECTED]> wrote:
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,
T
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 snapsh
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 Thu, Oct 05, 2006 at 02:19:46PM -0700, Erik Trimble 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
Hello,
On 10/6/06, [EMAIL PROTECTED] <[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 connec
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 tim
On Oct 6, 2006, at 1:07 AM, Michael Schuster wrote:
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
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 se
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,
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 call
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 -- Sh
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. An
On Oct 5, 2006, at 5:40 PM, Erik Trimble wrote:
And, try thinking of a directory with a few dozen files in it, each
with
a dozen or more versions. that's hideous, from a normal user
standpoint.
VMS's implementation of ; is completely unwieldy if
you have more than a few files,
No it is no
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. Dun
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
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 v
On Thu, Oct 05, 2006 at 04:40:09PM -0700, Erik Trimble wrote:
>
> So, here's a question: if I delete file X;1, do I delete X;x ? That
> is, do I delete all versions of a file when I delete the actual file?
> what about deleting a (non-head) version? And, exactly how many
Under VMS at least, th
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 tha
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 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.
>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,
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 *tremendo
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 i
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 .
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 . Snapshots, source
control, and other alternatives aren't, in fact, alternati
On Thu, Oct 05, 2006 at 10:18:18PM +0800, Jeremy Teo wrote:
> What would a version FS buy us that cron+ zfs snapshots doesn't?
Instant file copy. with cron you could make multiple changes between
snapshot runs.
-brian
___
zfs-discuss mailing list
zfs-d
97 matches
Mail list logo
