backup files for files under VC

backup files for files under VC

[Torsten Bronger]

Hallöchen!

Emacs does not create backup files for files covered by version
control.  I find this default unfortunate and request to change it
because the VCS only stores the last commit.

Especially with DVCS'es becoming increasingly popular with a lot of
branching and merging, these backup files can become very valuable.
(Well, yesterday they would have for me.  ;-)

Additionally, DVCS'es don't store last-commit files in the local
directory (in contrast to SVN or CVS) so that cluppering up is not
an issue either.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Re: backup files for files under VC

[Nick Roberts]

 > Emacs does not create backup files for files covered by version
 > control.  I find this default unfortunate and request to change it
 > because the VCS only stores the last commit.

See `vc-make-backup-files' in the Emacs manual.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: backup files for files under VC

[David Kastrup]

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> Emacs does not create backup files for files covered by version
> control.  I find this default unfortunate

I don't.  What version control system necessitates keeping backups
around?

> and request to change it because the VCS only stores the last commit.

What version control system would that be?

> Especially with DVCS'es becoming increasingly popular with a lot of
> branching and merging, these backup files can become very valuable.
> (Well, yesterday they would have for me.  ;-)

Again, which version control are you talking about?

> Additionally, DVCS'es don't store last-commit files in the local
> directory (in contrast to SVN or CVS) so that cluppering up is not an
> issue either.

I don't get your point here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: backup files for files under VC

[Torsten Bronger]

Hallöchen!

David Kastrup writes:

> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>
>> [...]
>>
>> and request to change it because the VCS only stores the last
>> commit.
>
> What version control system would that be?

If I change the file, save it, and remove it afterwards, the changes
are lost.  Between saving and removing must be the commit,
otherwise, the VCS can't restore the file.

In contrast to that, a backup file stores the last save instead of
the last commit.  And because this may help in some cases, I suggest
to change the default value of vc-make-backup-files.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Re: backup files for files under VC

[David Kastrup]

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> Hallöchen!
>
> David Kastrup writes:
>
>> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>>
>>> [...]
>>>
>>> and request to change it because the VCS only stores the last
>>> commit.
>>
>> What version control system would that be?
>
> If I change the file, save it, and remove it afterwards, the changes
> are lost.

Why would you do that without checking this into a branch when you have
serious work done on it?

> Between saving and removing must be the commit, otherwise, the VCS
> can't restore the file.

Random deletion is more a candidate for backing up your whole directory
rather than having single backup files lying around.

> In contrast to that, a backup file stores the last save instead of the
> last commit.  And because this may help in some cases, I suggest to
> change the default value of vc-make-backup-files.

I vote against it.  Version-controlled directories become messy pretty
fast with backup files lying around.  For one thing, they tend not to
correspond with the current branch/version.

In particular distributed version control systems (you still have not
mentioned which system you are talking about, by the way) provide ample
opportunity for saving partial work, in a manner where it is clear just
what version the partial work is based on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: backup files for files under VC

[Torsten Bronger]

Hallöchen!

David Kastrup writes:

> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>
>> [...]
>>
>> If I change the file, save it, and remove it afterwards, the
>> changes are lost.
>
> Why would you do that without checking this into a branch when you
> have serious work done on it?

You may do it accidentally.  Backups are a protection from hardware
failure as well as human errors.  I'm talking about the latter here.

> [...]
>
>> In contrast to that, a backup file stores the last save instead
>> of the last commit.  And because this may help in some cases, I
>> suggest to change the default value of vc-make-backup-files.
>
> I vote against it.  Version-controlled directories become messy
> pretty fast with backup files lying around.

People who find this messy may switch it off if they please.
However, I think that the default should be in faviour of safety.

Maybe my workflow is unusual -- I've never talked with other people
about it -- but I use C-x C-s much more often than C-x v v when
editing versioned files.  Therefore, I think it is also for these
files sensible to keep backups of the last save.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Re: backup files for files under VC

[David Kastrup]

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> David Kastrup writes:
>
>> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>>
>>> [...]
>>>
>>> If I change the file, save it, and remove it afterwards, the
>>> changes are lost.
>>
>> Why would you do that without checking this into a branch when you
>> have serious work done on it?
>
> You may do it accidentally.  Backups are a protection from hardware
> failure as well as human errors.  I'm talking about the latter here.

Human error with regard to backups is usually caused by overzealous
wildcards.  The usual backup files provide very little protection
against that and might give a false sense of security.

>> [...]
>>
>>> In contrast to that, a backup file stores the last save instead of
>>> the last commit.  And because this may help in some cases, I suggest
>>> to change the default value of vc-make-backup-files.
>>
>> I vote against it.  Version-controlled directories become messy
>> pretty fast with backup files lying around.
>
> People who find this messy may switch it off if they please.  However,
> I think that the default should be in faviour of safety.

People who find this safe may switch it on if they please.  But in my
book, the tradeoff between annoyance and usefulness for backup files
with versioning systems is not worth the trouble.  This decision has
been made at a time where we were talking pretty much only about
centralized versioning control systems, and the existence of distributed
versioning control tips the scale even further, since local branches
provide much better control over versioning and consistent state savings
than backup files.

> Maybe my workflow is unusual -- I've never talked with other people
> about it -- but I use C-x C-s much more often than C-x v v when
> editing versioned files.  Therefore, I think it is also for these
> files sensible to keep backups of the last save.

That's your opinion based on your workflow.  Mine is different.  And the
historic one seems different as well.  So let's see what others have to
say.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: backup files for files under VC

[Torsten Bronger]

Hallöchen!

David Kastrup writes:

> [...]  This decision has been made at a time where we were talking
> pretty much only about centralized versioning control systems, and
> the existence of distributed versioning control tips the scale
> even further, since local branches provide much better control
> over versioning and consistent state savings than backup files.

Note however that the distributed VCS'es don't store local copies of
the last revision as CVS and SVN do.  So you have only the original
files in the tree.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Re: backup files for files under VC

[David Kastrup]

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> David Kastrup writes:
>
>> [...]  This decision has been made at a time where we were talking
>> pretty much only about centralized versioning control systems, and
>> the existence of distributed versioning control tips the scale
>> even further, since local branches provide much better control
>> over versioning and consistent state savings than backup files.
>
> Note however that the distributed VCS'es don't store local copies of
> the last revision as CVS and SVN do.

Huh?  Most certainly I can check out the last revision any time from my
local version control system.

> So you have only the original files in the tree.

I can't make sense of what you are saying here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: backup files for files under VC

[Torsten Bronger]

Hallöchen!

David Kastrup writes:

> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>
>> David Kastrup writes:
>>
>>> [...]  This decision has been made at a time where we were talking
>>> pretty much only about centralized versioning control systems, and
>>> the existence of distributed versioning control tips the scale
>>> even further, since local branches provide much better control
>>> over versioning and consistent state savings than backup files.
>>
>> Note however that the distributed VCS'es don't store local copies
>> of the last revision as CVS and SVN do.
>
> Huh?  Most certainly I can check out the last revision any time
> from my local version control system.

I mean files like "thesis.tex.~1.3.~" in the same directory as your
working copies.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Re: backup files for files under VC

[David Kastrup]

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> Hallöchen!
>
> David Kastrup writes:
>
>> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>>
>>> David Kastrup writes:
>>>
>>>> [...]  This decision has been made at a time where we were talking
>>>> pretty much only about centralized versioning control systems, and
>>>> the existence of distributed versioning control tips the scale
>>>> even further, since local branches provide much better control
>>>> over versioning and consistent state savings than backup files.
>>>
>>> Note however that the distributed VCS'es don't store local copies
>>> of the last revision as CVS and SVN do.
>>
>> Huh?  Most certainly I can check out the last revision any time
>> from my local version control system.
>
> I mean files like "thesis.tex.~1.3.~" in the same directory as your
> working copies.

I think you are confused.  Those aren't created by the version control
system.  They are auxiliary files Emacs creates (or has the version
control system create) for its own operation when it can't perform them
otherwise.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: backup files for files under VC

[Torsten Bronger]

Hallöchen!

David Kastrup writes:

> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>
>> David Kastrup writes:
>>
>>> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>>>
>>>> David Kastrup writes:
>>>>
>>>>> [...]  This decision has been made at a time where we were
>>>>> talking pretty much only about centralized versioning control
>>>>> systems, and the existence of distributed versioning control
>>>>> tips the scale even further, since local branches provide much
>>>>> better control over versioning and consistent state savings
>>>>> than backup files.
>>>>
>>>> Note however that the distributed VCS'es don't store local
>>>> copies of the last revision as CVS and SVN do.
>>>
>>> Huh?  Most certainly I can check out the last revision any time
>>> from my local version control system.
>>
>> I mean files like "thesis.tex.~1.3.~" in the same directory as your
>> working copies.
>
> I think you are confused.  Those aren't created by the version
> control system.  They are auxiliary files Emacs creates (or has
> the version control system create) for its own operation when it
> can't perform them otherwise.

Okay, sorry to have misled you.  But actually their origin doesn't
matter for what I tried to get across.  The typical cluttering up
that they generate in SVN working copies, and which may justify
avoiding additional eyesore by backup files, doesn't occur in
DVCS'es.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Messy VC checkouts (was: backup files for files under VC)

[Phil Hagelberg]

David Kastrup <dak@gnu.org> writes:

>> I mean files like "thesis.tex.~1.3.~" in the same directory as your
>> working copies.
>
> I think you are confused.  Those aren't created by the version control
> system.  They are auxiliary files Emacs creates (or has the version
> control system create) for its own operation when it can't perform them
> otherwise.

Speaking of messy directories under VC, is there any way instead of
writing those files to disk they could be loaded directly into a buffer
so as not to clutter the checkout? Perhaps they could be checked out
into a temporary file first?

If this option doesn't currently exist in VC, how difficult would it be
to add?

-Phil

Re: Messy VC checkouts

[Stefan Monnier]

>>> I mean files like "thesis.tex.~1.3.~" in the same directory as your
>>> working copies.
>> 
>> I think you are confused.  Those aren't created by the version control
>> system.  They are auxiliary files Emacs creates (or has the version
>> control system create) for its own operation when it can't perform them
>> otherwise.

> Speaking of messy directories under VC, is there any way instead of
> writing those files to disk they could be loaded directly into a buffer
> so as not to clutter the checkout? Perhaps they could be checked out
> into a temporary file first?

> If this option doesn't currently exist in VC, how difficult would it be
> to add?

It would be a change in behavior for VC, but that's indeed what I do in
PCL-CVS: file revisions are opened in a buffer with buffer-file-name set
to a value similar to VC's but the buffer is not saved, so the file
doesn't exist.  You can create it by saving the buffer.


        Stefan

Re: Messy VC checkouts

[Thien-Thi Nguyen]

() Phil Hagelberg <phil@hagelb.org>
() Mon, 21 Apr 2008 10:20:48 -0700

   If this option doesn't currently exist in VC,
   how difficult would it be to add?

Not very.  One example is below.  Personally, i
bind `display-previous-revision' to `C-x v p'.

thi

____________________________________________
;;; display-previous-revision.el
;;;
;;; Copyright (C) 2004, 2007, 2008 Thien-Thi Nguyen
;;;
;;; This file is part of ttn's personal elisp library, released under
;;; the terms of the GNU General Public License as published by the
;;; Free Software Foundation; either version 3, or (at your option) any
;;; later version.  There is NO WARRANTY.  See file COPYING for details.
;;;
;;; Description: Display previous revision of a version-controlled file.

;;;###autoload
(defun display-previous-revision (file rev checkout-switches)
  "Display FILE revision REV w/ CHECKOUT-SWITCHES in a new buffer."
  (interactive "fFile: \nsRevision (symbolic ok): \nsCheckout switches: ")
  (let ((vc-checkout-switches (unless (string= "" checkout-switches)
                                checkout-switches)))
    (switch-to-buffer (vc-find-revision file (if (string-equal rev "")
                                                 (vc-working-revision file)
                                               rev))))
  (delete-file buffer-file-name)
  (string-match "~\\(.+\\)~$" buffer-file-name)
  (setq rev (match-string 1 buffer-file-name)
        buffer-file-name nil)
  (rename-buffer (format "*%s:%s*" (file-name-nondirectory file) rev)))

(provide 'display-previous-revision)

;;; display-previous-revision.el ends here

Re: backup files for files under VC

[Richard Stallman]

    > Note however that the distributed VCS'es don't store local copies of
    > the last revision as CVS and SVN do.

    Huh?  Most certainly I can check out the last revision any time from my
    local version control system.

I strongly suspect that this is a miscommunication.
I do not know enough facts to disentangle it, though.

Re: backup files for files under VC

[Stefan Monnier]

> Note however that the distributed VCS'es don't store local copies of
> the last revision as CVS and SVN do.  So you have only the original
> files in the tree.

I'm not sure I understand correctly what you mean, but
Git/Bzr/Hg/Mtn/DaRCS do store the last revision (and all previous ones,
actually) locally.  It's "hidden" inside their internal data, but you
can access it with C-x v ~ any time (and presumably very quickly).


        Stefan

Re: backup files for files under VC

[Torsten Bronger]

Hallöchen!

Stefan Monnier writes:

>> Note however that the distributed VCS'es don't store local copies
>> of the last revision as CVS and SVN do.  So you have only the
>> original files in the tree.
>
> I'm not sure I understand correctly what you mean, but
> Git/Bzr/Hg/Mtn/DaRCS do store the last revision (and all previous
> ones, actually) locally.

As I already said, I emant the "thesis.tex.~1.13~" files in the tree
that you look at actually because David said "version-controlled
directories become messy pretty [...]".

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Re: backup files for files under VC

[David Kastrup]

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> Stefan Monnier writes:
>
>>> Note however that the distributed VCS'es don't store local copies
>>> of the last revision as CVS and SVN do.  So you have only the
>>> original files in the tree.
>>
>> I'm not sure I understand correctly what you mean, but
>> Git/Bzr/Hg/Mtn/DaRCS do store the last revision (and all previous
>> ones, actually) locally.
>
> As I already said, I emant the "thesis.tex.~1.13~" files in the tree
> that you look at actually because David said "version-controlled
> directories become messy pretty [...]".

I don't see the relation to your proposal.  Those files are not affected
by vc-make-backup-files either way.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: backup files for files under VC

[Torsten Bronger]

Hallöchen!

David Kastrup writes:

> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>
>> Stefan Monnier writes:
>>
>>>> Note however that the distributed VCS'es don't store local
>>>> copies of the last revision as CVS and SVN do.  So you have
>>>> only the original files in the tree.
>>>
>>> I'm not sure I understand correctly what you mean, but
>>> Git/Bzr/Hg/Mtn/DaRCS do store the last revision (and all
>>> previous ones, actually) locally.
>>
>> As I already said, I emant the "thesis.tex.~1.13~" files in the
>> tree that you look at actually because David said
>> "version-controlled directories become messy pretty [...]".
>
> I don't see the relation to your proposal.  Those files are not
> affected by vc-make-backup-files either way.

Then I don't understand what you meant with "messy".

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                                      Jabber ID: bronger@jabber.org
               (See http://ime.webhop.org for further contact info.)

Re: backup files for files under VC

[Stefan Monnier]

>>>> [...]
>>>> 
>>>> and request to change it because the VCS only stores the last
>>>> commit.
>>> 
>>> What version control system would that be?
>> 
>> If I change the file, save it, and remove it afterwards, the changes
>> are lost.

> Why would you do that without checking this into a branch when you have
> serious work done on it?

This is not a good question: clearly something like this has happened to
Torsten, and clearly it can happen to the best of us.

As for the issue at hand, I agree with Torsten that there is a risk of
losing some data.  Setting vc-make-backup-files to a non-nil value can
reduce this risk.  But note that it does not eliminate the risk.

Experience seems to indicate that for most people, the kind of "backup"
provided by VCS is at least as good as the one provided by Emacs's
backup files, so I think it's best to keep vc-make-backup-files set to
nil by default.

Also if the problem you saw was that after:

1 - edit file
2 - "cvs remove" (or "git remove" or "bzr remove")

the edit was lost, maybe the right place to solve it is in cvs/git/bzr:
revision control systems generally place a lot of emphasis on not losing
any data, so they may/should provide a way to undo the "cvs remove" and
recover the edits you've made in "file".


        Stefan

Re: backup files for files under VC

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Also if the problem you saw was that after:
>
> 1 - edit file
> 2 - "cvs remove" (or "git remove" or "bzr remove")
>
> the edit was lost, maybe the right place to solve it is in
> cvs/git/bzr: revision control systems generally place a lot of
> emphasis on not losing any data, so they may/should provide a way to
> undo the "cvs remove" and recover the edits you've made in "file".

It is actually quite hard to do a terminal mistake when using git.
Pretty much everything is recorded in the reflog, and you can rewind to
any intermediate state in the last 3 months or so.

The downside is of course that accidentally checked-in large amounts of
binary garbage are rather hard to get out of the system in a way that
they stop taking disk space.

Anyway, Torsten still has not reported what version control he is using
and what particular problem he encountered.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum