Merge lp:~jelmer/bzr-builddeb/709602-fix-duplicate-versions into lp:bzr-builddeb

Proposed by Jelmer Vernooij
Status: Merged
Merged at revision: 503
Proposed branch: lp:~jelmer/bzr-builddeb/709602-fix-duplicate-versions
Merge into: lp:bzr-builddeb
Diff against target: 24 lines (+4/-1)
1 file modified
cmds.py (+4/-1)
To merge this branch: bzr merge lp:~jelmer/bzr-builddeb/709602-fix-duplicate-versions
Reviewer Review Type Date Requested Status
James Westby Approve
Review via email: mp+47947@code.launchpad.net

Description of the change

This makes 'bzr merge-upstream' error out if it's being used in merge mode and the version that's being merged is already present.

(No changelog entry as this is a bug in a feature that's not been released yet)

To post a comment you must log in.
Revision history for this message
Jelmer Vernooij (jelmer) wrote :

Actually, looks like there was a similar bug open about non-merge-mode merging of old versions. changelog updated.

Revision history for this message
James Westby (james-w) wrote :

We might want force to override this? I can't think of a good reason for someone to do it right now though.

Thanks,

James

review: Approve
Revision history for this message
Jelmer Vernooij (jelmer) wrote :

On Mon, Jan 31, 2011 at 03:51:11PM -0000, James Westby wrote:
> Review: Approve
> We might want force to override this? I can't think of a good reason for someone to do it right now though.
Hmm, yeah. I wonder how that would work with merge - would we want to reset the
tree back to the old version? I guess we could wait until somebody files a wishlist
bug about this?

Cheers,

Jelmer

Revision history for this message
James Westby (james-w) wrote :

On Mon, 31 Jan 2011 18:48:59 -0000, Jelmer Vernooij <email address hidden> wrote:
> On Mon, Jan 31, 2011 at 03:51:11PM -0000, James Westby wrote:
> > Review: Approve
> > We might want force to override this? I can't think of a good reason for someone to do it right now though.
> Hmm, yeah. I wonder how that would work with merge - would we want to reset the
> tree back to the old version? I guess we could wait until somebody files a wishlist
> bug about this?

I don't see why not.

I think that --force is a good thing to have so that you don't get it
people's way, but only when you can make a sensible guess at what it
should do in that situation.

Thanks,

James

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'cmds.py'
2--- cmds.py 2011-01-29 02:51:40 +0000
3+++ cmds.py 2011-01-30 23:40:50 +0000
4@@ -708,9 +708,9 @@
5 if need_upstream_tarball:
6 location = primary_upstream_source.fetch_tarball(
7 package, version, target_dir)
8- note("Using version string %s." % (version))
9 if version is None:
10 raise BzrCommandError("You must specify the version number using --version.")
11+ note("Using version string %s." % (version))
12 # Look up the revision id from the version string
13 if upstream_revision is None and upstream_branch_source is not None:
14 upstream_revision = upstream_branch_source.version_as_revision(
15@@ -722,6 +722,9 @@
16 conflicts = self._do_merge(tree, tarball_filename, version,
17 current_version, upstream_branch, upstream_revision,
18 merge_type, force)
19+ if Version(current_version) >= Version(version):
20+ raise BzrCommandError(
21+ "Upstream version %s has already been merged." % version)
22 self._add_changelog_entry(tree, package, version,
23 distribution_name, changelog)
24 finally:

Subscribers

People subscribed via source and target branches