0.18: checking removes files automatically?

[Andrew King]

On 8/20/07, Andrew Voznytsa <andrew.voznytsa at gmail.com> wrote:
> >
> > 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 ...)
>
> IMHO, if any change is need at all, --rm-missing option might be added to
> allow users commit changes set with missing files. Plus auto-rm-missing
> =on/off in bazaar config for these who likes old behavior.
>
> From my experience I removed a few files by mistake once, committing
> changeset with missing files. After that I learned a few new commands (diff,
> bundle, merge, etc) and at the end it was rather plus than minus for me.
>
> > 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.
>
> Does not it mean that real problem is laziness? From my small practice, if I
> need to solve something I need to find root of problem and start playing
> from there.
>
> I.e. if I'm crashing my car every time as I drive then what should I do to
> eliminate this? Build new autobahn or learn driving?

Well, I said part of the problem. I really disagree with the current
practice, and potentially it is because I am seeing things on a scale
that other people aren't at the moment.

For instance, I had to do a merge the other day with 60 conflicts.
Apart from this there were many files removed, and many files added.
(Unfortunately for the time being, we have 2 fairly separate branches
being maintained with a lot of work being done in both).

Many of the files being removed or added were not in areas I was
familiar with. There were no conflicts though, so that is fine.

The problem then though is if I accidentally did something (like
dragged a file out of a folder by mistake or something), then bzr will
mark the file as removed.

Out of a list of 25 removed files currenly in my pending merge, how am
I to tell that there is one in there that I have accidentally removed?
I will just assume someone else has removed it, and happily commit,
only for someone else to be horrified later when uncommit is no longer
an option.

I really REALLY disagree that this is desired behaviour on
environments with > 5 users or so, or where people use more than a
command line to manage their files.

I think we should restore the old behaviour and make the new behaviour optional.

Regards,
Andrew