Comment 3 for bug 249546

On Fri, 2008-07-25 at 17:24 +0000, Scott Scriven wrote:
> In the second case, an actual branch, 'push' is probably the wrong
> command to use; 'send' or 'merge' would be appropriate instead. Bzr may
> not know the difference between a real branch and a mere copy of trunk,
> but the user does.

No, neither send or merge allow me to publish my feature branch
to a public server to allow someone else to look at it.

>
> I suppose, in theory, the worst case is that someone could break the
> trunk until an 'uncommit' is performed.

That's true. However, the feature branch may be very immature
and really break things, or cause data corruption for anyone that
used it or similar, so while having a version control system
allows you to clean it up the intervening period when the feature
branch is claiming to be trunk.

There is another, smaller, issue, that anyone that pulls in the
intervening period must pull --overwrite or similar to get back
to what they had before. This gets more complicated if they have
based work on top of it, or merged in trunk and then continued.

These problems obviously exist now, without the change that you
propose, but my argument is that your change would make them
more likely.

> However, giving trunk write
> access to a sloppy or inexperienced developer seems more like a people
> problem.

That is true. However, I don't think that you necessarily have to
be sloppy to trip over this. "hack; commit; push" can be your
routine, whether you are working on trunk or a feature branch.
The difference comes with the first push, which could be a long
while after creating the branch. I think the safety catch is
a good thing to have here.

> In practice, I doubt a default push URL would cause problems, because
> hg, git, darcs, bitkeeper, and svk behave this way and nobody seems to
> complain about it.

I haven't heard complaints, though I haven't been looking. What
we don't know is how many people have tripped over this though.

> So, should bzr assume the user meant what they said (and facilitate the
> process), or should it assume the user made a mistake?

We're not assuming they made a mistake as such, just that they
haven't provided the information about what they intend yet.

> ** Changed in: bzr
> Status: Won't Fix => New

You haven't yet convinced me, but I won't change this back. If
another developer feels the same way then they can do so. If someone
agrees with you they can confirm the bug and work on the patch.

This should be an easy patch to create, so if you really want this
change then you could send a merge request to the list. At the review
stage is where we would find out if this is really "Won't Fix".

Thanks,

James