[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New names for VC local version backups

From: Andre Spiegel
Subject: Re: New names for VC local version backups
Date: 26 Oct 2000 12:03:55 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7

"Eli Zaretskii" <address@hidden> writes in response to me:

> > Hmm, this doesn't appeal to me.  It would result in an explosion of
> > subdirectories under `versions'. 
> Only for as long as you keep the relevant versions.

Ok, that's a temporary explosion then :-).

> > It would be difficult to find a version of a particular file if you
> > don't happen to know the version number.
> I don't see anything that "find -name" couldn't solve.

Sure, but I didn't say "impossible", I said "difficult" :-).  Having
to run "find" just in order to find a file I presume is there but it
is two levels below where I am and I just don't know where precisely
it is...  (See my separate reply to Kai regarding the alternative.)

> > Completely unrelated files would end up in the same
> > subdirectory only because they happen to have the same version number.
> This happens today: we have *all* the files in the same directory.

Well, for example, we have all Emacs lisp files in the same directory,
plus any backup versions of them.  So they are related by being "the
Emacs lisp files", and it has always been the case that backups are
kept along with them by default.  But to have a directory containing
all Emacs lisp files currently at version 1.17, and another one
containing all those at version 1.408 seems like a somewhat strange
directory structure to me...

[And regarding the file.~rev~ idea under MS-DOS...]

> > I think that's what we should do.
> What, the first alternative or the second?  They are mutually
> exclusive.

Err, sorry, bad quote context.  I mean that we should decide that the
feature does not work under MS-DOS and make sure that it does get
disabled.  Along the lines of what you wrote.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]