© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
This is a Sun/MySQL - Canonical escalation imported into Launchpad by the Canonical Support Team.
Original escalation: 15/12/2008 9:58 AM EST
Public bug: https:/
===
Guilhem Bichot
Hello,
Out of the 100 MySQL developers who do bzr merges, we see that sometimes some accidentally commit .OTHER/
I imagined that I could just do
bzr ignore *.moved
then commit that change and push, and it would prevent my colleagues, once they pull my change, to ever commit some *.moved files. But no. After doing the commit above, I can "touch a.moved; bzr add a.moved" and bzr does not complain, I can commit a.moved, it gets in the branch. I can rename a file to b.moved, no complaint either.
Whereas if I first add a.moved and then do "bzr ignore '*.moved' then I get a warning:
[INS 15:46 /tmp/weirdbug/br3 $] bzr ignore '*.moved'
Warning: the following files are version controlled and match your ignore pattern:
a.moved
Why don't "bzr add" and "bzr mv" just loudly fail if the new file name should be ignored according to ignore rules?
===
So the immediate answer is that ignore, consistently with cvs and svn,
the ignore patterns only determine whether unversioned files are treated
as unknown or ignored. The idea is that people may sometimes want to
add exceptions, and in any case it may be possible that a previously
added file will later match an ignore pattern.
It does seem reasonable that we could upgrade the warning given by 'bzr
add' to be a failure, at least if there is an option to override it, and
add a check for 'bzr mv' against renames to ignored names.
I filed <https:/
Normally commit will stop with an error if there are any unresolved
conflicts in the tree, and this is intended to prevent accidental
commits of conflict files. Running 'bzr resolve' should remove the
.BASE/.THIS/.OTHER files, and they will not be versioned unless you
explicitly add them.
*.moved files work a bit differently because they are already added.
However, they should be guarded from commit by the conflict list. So
I'd be interested to hear if this is not working in some way, or if
people are forcing bzr resolve on these files, and then committing. If
so, it may be 'bzr resolve' that should give a warning or error.
===
> "How to avoid that people commit .OTHER/
That could be a commit policy implemented via a pre_commit_hook
that will abort the commit if any change looks like an unresolved
conflict...
But since commit already checks that conflicts have been
resolved, I'm afraid people will also work around that hook..
> Out of the 100 MySQL developers who do bzr merges, we
> see that sometimes some accidentally commit
> .OTHER/
> repository. Most often, *.moved. To excuse them, there
> are sometimes path conflicts which shouldn't be (ok,
> let's not get started on this :) ,
I really think the root cause is that conflicts could (should ?)
be better explained and easier to solve so that people really
solve them and don't commit .OTHER/
If the people committing these files don't realize that they are
making other people life harder, I'm not sure that making *their*
life harder is the solution.
> so .moved files are common. I imagined that I could
> just do bzr ignore *.moved then commit that change and
> push, and it would prevent my colleagues, once they
> pull my change, to ever commit some *.moved files. But
> no. After doing the commit above, I can "touch
> a.moved; bzr add a.moved" and bzr does not complain, I
> can commit a.moved, it gets in the branch. I can
> rename a file to b.moved, no complaint either.
> Whereas if I first add a.moved and then do "bzr ignore
> '*.moved' then I get a warning: [INS 15:46
> /tmp/weirdbug/br3 $] bzr ignore '*.moved' Warning: the
> following files are version controlled and match your
> ignore pattern: a.moved
> Why don't "bzr add" and "bzr mv" just loudly fail if
> the new file name should be ignored according to
> ignore rules?"
That's by design so that ignore rules can be overridden when
needed.
===
Guilhem Bichot (18/12/2008 9:22 AM)
Hello. Thanks for the replies. So what remains mostly is those .moved files; yes it's possible to commit them "by accident"; what happened several times already is that in some bzr criss-cross merges, some non-bzr-expert people get path conflicts which should not be and then just "bzr resolve". In that case, the .moved file stays, and "bzr commit" does not complain.
How about making "bzr resolve" fail (always fail, no option) if the .moved file is still present, giving an informative error message?
In the case at point, it was not a path conflict, it was
"Duplicate paths
---------------
Typical message:
Conflict adding file FILE. Moved existing file to FILE.moved.
Sometimes Bazaar will attempt to create a file using a pathname that has
already been used. The existing file will be renamed to "FILE.moved". If
you wish, you can rename either one of these files, or combine their contents.
When you are satisfied, you can run "bzr resolve FILE" to mark the conflict as
resolved.
"