Cannot commit to bound svn branch: "invalid property value 'branch-nick' for None"

[CodyC]

Out of curiosity, I tried to reproduce the bzr-svn bug detailed here:
https://bugs.launchpad.net/bzr-svn/+bug/248289

with:
* bzr 1.9rc1
* bzr-svn 1.4.15dev0

Unfortunately, I discovered that I'm completely unable to commit to a bound svn branch. I can unbind, commit, and push as separate steps, but committing to a bound branch yields the following stack trace:

Committing to: /Users/codyc/test/svnrepo/test
modified test
bzr: ERROR: exceptions.ValueError: invalid property value 'branch-nick' for None

Traceback (most recent call last):
  File "/Library/Python/2.5/site-packages/bzrlib/commands.py", line 893, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/Library/Python/2.5/site-packages/bzrlib/commands.py", line 839, in run_bzr
    ret = run(*run_argv)
  File "/Library/Python/2.5/site-packages/bzrlib/commands.py", line 539, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/Library/Python/2.5/site-packages/bzrlib/builtins.py", line 2431, in run
    exclude=safe_relpath_files(tree, exclude))
  File "/Library/Python/2.5/site-packages/bzrlib/decorators.py", line 192, in write_locked
    result = unbound(self, *args, **kwargs)
  File "/Library/Python/2.5/site-packages/bzrlib/workingtree_4.py", line 237, in commit
    result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  File "/Library/Python/2.5/site-packages/bzrlib/decorators.py", line 192, in write_locked
    result = unbound(self, *args, **kwargs)
  File "/Library/Python/2.5/site-packages/bzrlib/mutabletree.py", line 201, in commit
    *args, **kwargs)
  File "/Library/Python/2.5/site-packages/bzrlib/commit.py", line 385, in commit
    self.rev_id = self.builder.commit(self.message)
  File "/Library/Python/2.5/site-packages/bzrlib/repository.py", line 132, in commit
    properties=self._revprops)
  File "/Library/Python/2.5/site-packages/bzrlib/revision.py", line 57, in __init__
    self._check_properties()
  File "/Library/Python/2.5/site-packages/bzrlib/revision.py", line 89, in _check_properties
    (name, value))
ValueError: invalid property value 'branch-nick' for None

[Jelmer Vernooij (jelmer)]

I think this is a regression in the bzr API - Branch._get_nick() now assumes that the master branch has a config with a nickname set rather than just using the "nick" setting in the master branch.

[Robert Collins (lifeless)]

On Tue, 2008-11-04 at 04:23 +0000, Jelmer Vernooij wrote:
> I think this is a regression in the bzr API - Branch._get_nick() now
> assumes that the master branch has a config with a nickname set rather
> than just using the "nick" setting in the master branch.

Makes sense to me.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Jelmer Vernooij (jelmer)]

EAMBIGUOUS

Do you mean the way it works now makes sense or my claim that the API was broken?

[Robert Collins (lifeless)]

On Tue, 2008-11-04 at 05:21 +0000, Jelmer Vernooij wrote:
> EAMBIGUOUS
>
> Do you mean the way it works now makes sense or my claim that the API
> was broken?

Your claim :)

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Martin Pool (mbp)]

This does seem like an API regression.

[Martin Pool (mbp)]

Like this?

=== modified file 'bzrlib/branch.py'
--- bzrlib/branch.py 2008-10-30 03:56:00 +0000
+++ bzrlib/branch.py 2008-11-07 05:48:35 +0000
@@ -155,7 +155,7 @@
                 master = self.get_master_branch(possible_transports)
                 if master is not None:
                     # return the master branch value
- config = master.get_config()
+ return master.nick
             except errors.BzrError, e:
                 # Silently fall back to local implicit nick if the master is
                 # unavailable

[Jelmer Vernooij (jelmer)]

Yeah, that should indeed take care of it.

1.9 claims it has this fixed, but the tarball doesn't contain this change.

[Jelmer Vernooij (jelmer)]

Fix hasn't made it into the release or bzr.dev.

[Marius Kruger (amanica)]

I can confirm that Martin's proposed fix fixes the problem, and that it is not in bzr.dev or https://code.launchpad.net/~bzr/bzr/bzr.1.9 (I think you accidentally missed the actual change when merging)

Will you please merge it (at least into bzr.dev), or should I submit a patch?

BTW. thanks a lot Martin for looking into this.

[Robert Collins (lifeless)]

please do not make incorrect changes to bug status

[Jelmer Vernooij (jelmer)]

CodyC, why did you change the status of this bug?

[CodyC (cody-casterline)]

I marked it as incomplete because there are comments above (2 from Jelmer, one from Marius) that that say that these changes have NOT been committed to 1.9final. (which I discovered myself, as well.) So, "fix commeted, 1.9final" seems to be the incorrect status. Is that not the case?

Also, I was just curious if I had permission to do so. ;) Sorry of I broke some Launchpad/bzr etiquette.

[John A Meinel (jameinel)]

Incomplete means that the bug itself is incomplete (not completely defined).

In Progress means that someone is working on a fix, but has not finished it.
Fix Committed means that the fix has been finished by someone, and is pending review to get merged.
Fix Released means that it has been merged into mainline.

http://bazaar-vcs.org/BugGuidelines

We have talked about making "Fix Released" mean it has showed up in a released tarball, which would make Fix Committed mean it is merged into bzr.dev, etc. But that would mean at best the bug should be marked "In Progress" since the bug itself is well defined, even if the patch has not been finished/merged.

Incomplete is used to mean that we need more information before we can determine if there really is a bug, etc.

[Martin Pool (mbp)]

This missed 1.9 but it's merged to the 1.9 branch (by me) and I think by Jelmer to trunk, for inclusion in 1.9.1 or 1.10

[Marius Kruger (amanica)]

Its not in thr trunk yet.

http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640811181405n7c1a65c1i64e15875eddaf6cf%40mail.gmail.com%3E

[Marius Kruger (amanica)]

Its not in the trunk yet.

http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C418c22640811181405n7c1a65c1i64e15875eddaf6cf%40mail.gmail.com%3E

[Marius Kruger (amanica)]

it was finally merged into bzr.dev today

[Eric Ferraiuolo (eferraiuolo)]

When I should I expect this fix to appear in the Mac OS X installer?

[Grant Rettke (grettke)]

When will we see this fix in an official release?

[Marius Kruger (amanica)]

this would be in the next release (should happen pretty soon): 1.10 for
which the release candidate is already available for public download.