Conflict while using "bzr pull"
James Blackwell
jblack at merconline.com
Sat Dec 17 12:54:14 GMT 2005
On Thu, Dec 15, 2005 at 04:12:35PM +1100, Jamie Wilkinson wrote:
> This one time, at band camp, James Blackwell wrote:
> >There is still a need for --full for a different reason. Many sorts of
> >problems can (and likely will) rear up from time to time as people bump
> >into undefined behaviours. We know a priori that when users start bumping
> >into undefined behaviour that the right solution is to expose the problem
> >so that the proper behaviour can be defined.
>
> I agree with your hypothesis, but adding to bzr a command to work around
> future bugs says to me "the offical way forward is to not report this bug,
> just run this command and it'll be like it never happened." I posit that
> making it easier for people to not report bugs will increase entropy and
> accelerate the heat death of the universe :)
>
> More seriously, I think adding support in bzr to workaround potential
> bugs with merge or pull a lot of effort for little gain.
I see your point. We don't the community getting into the habit of blowing
away symptomatic behaviour of a bug unless we already know about it.
After all, problems do tend to worsen over time.
Looking at it pragmatically, I think we both need that users need some way
to unwedge a tree while they wait for a new release. I think we both
agree that users have a need to unbreak trees that can't be done with a
standard revert. I think we only disagree on the method, inasmuch as I
propose a --full option while you propose "rm -r *".
I like rm -r * because it can have very surprising results if one is't
paying good attention to which directory they're in when they run it.
With the number of users congnizant that a failing "bzr revert"
underscores an underlying problem that needs to be addressed, we don't
need to worry about making the process difficult just to ensure bug
reports. John Meinel was involved in this thread for example.
So, presuming that we want uses to be able to fix a potentially repeatable
problem, we should want to provide a safer option than a command that can
take out most of $HOME if the user forgets that he just ran "cd".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051217/5b1f09da/attachment.pgp
More information about the bazaar
mailing list