0.18: checking removes files automatically?

Andrew King eurokang at gmail.com
Mon Aug 20 09:26:08 BST 2007


Sorry, I created a new message before reading this one, but I will
quote bits from my original:

I am really not sure that marking files as removed if they are missing
is what most users want. Particularly on Windows (yes, yes, I know),
it is all too easy to move a file by mistake, then not read the commit
message carefully, and remove a whole lot of files. This situation
gets a lot worse when said user decides to fix the problem by
re-adding the file. How else do they get around the problem? They
can't revert the revision because then they lose all their other
changes! Most users will just try and re-add to get around it. This
means of course (currently in bzr) you lose ALL versioning info on the
file.

IMHO, I think it is necessary to mark the file as *missing* (as
it used to?) and not allow a commit unless the file was explicitly bzr
rm'ed or bzr reverted. (eg. uncommitted changes in working tree ...)

I think this also applies to rename.

I think a lot of our merge issues have come down to lazy users
accidentally deleting then re-adding files, and causing conflicts days
later down the track when big merges are attempted.

By the way, what is the correct way for a user do to fix a problem
when they have committed a revision with a file being incorrectly
removed?

Thoughts?

Cheers,
Andrew.



More information about the bazaar mailing list