Bazaar

Code review comment for lp:~jelmer/bzr/overwrite-tags

overwrite-tags
Merge into bzr.dev

Revision history for this message

Jelmer Vernooij (jelmer) wrote on 2012-03-13:

Am 13/03/12 10:40, schrieb Vincent Ladeuil:
>> It's come up a few times (the emacs folks have asked about it too), so I
>> would argue it's not unheard of. I don't really see the harm in adding a
>> option for "bzr push" / "bzr pull" and a command-line option is a lot
>> more discoverable than a configuration option.
> The fact that it's more exposed means more work associated with removing it
> which is my point. Yes, some people need this option, I agree with that or I
> wouldn't search for a way to land the associated feature :)
I don't think we'll ever want to remove this option if we add it. There
are plenty of formats that don't support versioned tags and some of them
aren't going to go away (e.g. git, 2a, etc).
>
>> This also doesn't really
>> seem appropriate as a configuration option since you wouldn't really
>> want to set this option in e.g. branch.conf any more than you would want
>> to set 'overwrite = True'.
> I disagree with that, if I maintaining an official branch mirrored to
> apublic website I very well want to set this option locally.
By that reasoning "overwrite" should be a configuration option rather
than a command-line option too.... ?
>>> How about landing this stuff behind a config option and *then* discuss about
>> adding the parameter to have some progress ? That would even allow landing in
>> 2.5 in this case as this will not break compatibility (assuming you update the
>> foreign plugins accordingly).
>> Doing this will break compatibility no more or less than my patch does,
>> in that anything that doesn't support it will ignore it and anything
>> that does support it will.
> It won't break the command-line compatibility which is exactly what I'm
> arguing against.
How is adding a new command-line option breaking command-line compatibility?

If you mean that we'll break compatibility if we remove this
command-line option later then I think that a configuration option is no
better. In fact, in the case of a configuration option we'll *silently*
ignore what the user specified, which is probably a lot more confusing.

Cheers,

Jelmer

Am 13/03/12 10:40, schrieb Vincent Ladeuil:
>> It's come up a few times (the emacs folks have asked about it too), so I
>> would argue it's not unheard of. I don't really see the harm in adding a
>> option for "bzr push" / "bzr pull" and a command-line option is a lot
>> more discoverable than a configuration option.
> The fact that it's more exposed means more work associated with removing it
> which is my point. Yes, some people need this option, I agree with that or I
> wouldn't search for a way to land the associated feature :)
I don't think we'll ever want to remove this option if we add it. There 
are plenty of formats that don't support versioned tags and some of them 
aren't going to go away (e.g. git, 2a, etc).
>
>> This also doesn't really
>> seem appropriate as a configuration option since you wouldn't really
>> want to set this option in e.g. branch.conf any more than you would want
>> to set 'overwrite = True'.
> I disagree with that, if I maintaining an official branch mirrored to
> apublic website I very well want to set this option locally.
By that reasoning "overwrite" should be a configuration option rather 
than a command-line option too.... ?
>>> How about landing this stuff behind a config option and *then* discuss about
>> adding the parameter to have some progress ? That would even allow landing in
>> 2.5 in this case as this will not break compatibility (assuming you update the
>> foreign plugins accordingly).
>> Doing this will break compatibility no more or less than my patch does,
>> in that anything that doesn't support it will ignore it and anything
>> that does support it will.
> It won't break the command-line compatibility which is exactly what I'm
> arguing against.
How is adding a new command-line option breaking command-line compatibility?

If you mean that we'll break compatibility if we remove this 
command-line option later then I think that a configuration option is no 
better. In fact, in the case of a configuration option we'll *silently* 
ignore what the user specified, which is probably a lot more confusing.

Cheers,

Jelmer

« Back to merge proposal