bzr revert should place backup files under .bzr/backups (or similar)

[Geoff Bache]

I find that after a while of developing my working tree gets cluttered with backup files, which I dislike. So I made bzr revert
an alias for bzr revert --no-backup (as I rarely want the backup files, and our system is backed up every hour anyway) but recently had reason to regret this.

I would find it much more usable if these files didn't get litter my working tree but ended up somewhere under .bzr, say .bzr/backups. It would then also be much easier to clean them all in one go.

[Wouter van Heyst (larstiq)]

On Thu, Mar 19, 2009 at 07:42:36PM -0000, Geoff Bache wrote:
> Public bug reported:
>
> I find that after a while of developing my working tree gets cluttered with backup files, which I dislike. So I made bzr revert
> an alias for bzr revert --no-backup (as I rarely want the backup files, and our system is backed up every hour anyway) but recently had reason to regret this.
>
> I would find it much more usable if these files didn't get litter my
> working tree but ended up somewhere under .bzr, say .bzr/backups. It
> would then also be much easier to clean them all in one go.

The latter can be done with the clean-tree command. Is then the former
still a problem?

Wouter

[Geoff Bache (geoff.bache)]

Thanks for the tip, didn't know about clean-tree (have been using 1.11 until today...) That diminishes the size of the problem, but I don't think it goes away entirely.

It's still something I need to remember to do semi-regularly or my working tree gets very cluttered. Lots of programs exist that don't realise that these are just Bazaar backup files and should almost always be ignored (they don't follow the naming conventions of other programs' backup files that I've seen). Even emacs, which knows about bzr, doesn't exclude them from its searches, but it does know not to look under .bzr.

If they lived in .bzr I wouldn't need to worry about them at all except in the rare cases when I actually want to retrieve them. Or I start running low on disk space...

It's basically all about the probability you're actually going to want something. If there is a conflict when merging then it makes sense to put files in the working tree because you know the user has to do something about it. If there's only a 1% chance the user will ever want the file it's much better to hide it away.

[Simon (simonjwiles)]

I would like to second this suggestion - it actually took me a short while just now to work out where these files had come from. I can't see the logic behind storing them in the working tree, to be honest. on my pros/cons list, there's nothing on the pros side....!

[Parth Malwankar (parthm)]

I suppose this is a somewhat subjective topic.
Personally, I prefer the current behavior of bzr. As I see the backup files in the same location as the actual file, I find it convenient to do things like diffing, editing both copies for copy paste etc. I periodically use the clean-tree command to remove these file. As bzr ignores these by default the command line for bzr is convenient to use. Its convenient to have files in the original folder for deeply nested trees, especially for command line users.

Perhaps 'revert' can take an option allowing users to specify a backup location. There is also the case that if user does 'bzr revert --backup-dir=foo' and two files of the same name need to be backed up, what would be the correct behavior in such a case? Maybe path information can be retained. So if we have file 'a/b/c.py' and 'a/c.py' to be backed up and user does 'bzr rever --backup-dir=foo' the files are put in 'foo/a/b/c.py.~1~' and 'foo/a/c.py.~1~'.

[Martin Pool (mbp)]

I'd like to add a config option that controls the general behaviour of
"I need to remove a user file" - this is useful not just in revert but
also update, merge, ... anything that transforms the tree.

--
Martin <http://launchpad.net/~mbp/>

[Robert Collins (lifeless)]

Worth thinking about when doing that is the idea that the user may not
care about some files.

[Martin Pool (mbp)]

On 27 May 2010 10:20, Robert Collins <email address hidden> wrote:
> Worth thinking about when doing that is the idea that the user may not
> care about some files.

Right, which links to the idea of having _optional_ categorization of
non-versioned files as backup, junk, precious, etc. I think you could
'generally backup everything except not those classified as junk;
*.pyc is junk". Or perhaps there's a better way.

--
Martin <http://launchpad.net/~mbp/>