Revisions added while a commit is happening are ignored

Bug #515850 reported by Huw Giddens on 2010-02-02
58
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Bazaar Subversion Plugin
High
Jelmer Vernooij

Bug Description

It is possible for another user to commit a revision between the beginning and end of a commit from bzr-svn. This leads to the bzr:base-revision property being set incorrectly, the interleaving revision being invisible to bzr clients, and a mangled tree.

For example, I have a checkout of a Subversion branch, from which I made a topic branch and modified a file. I merged the topic branch into my checkout, and ran 'bzr ci -m "blah blah blah"'. Before my commit completed, my co-worker commited a change to another file in the same Subversion branch using svn. His commit completes first and is revision x, mine completes immediately afterwards and is revision x+1. However, my commit x+1 has it's bzr:base-revision property set to x-1 rather than x. Subversion revision x doesn't appear in the output from bzr log, and the revision's changes are not reflected in the tree.

Manually tweaking bzr:base-revision fixes this for branches I make in new repositories, but how can I fix the branches in my existing repository?

Related branches

On Tue, 2010-02-02 at 04:31 +0000, Huw Giddens wrote:
> Public bug reported:
>
> It is possible for another user to commit a revision between the
> beginning and end of a commit from bzr-svn. This leads to the bzr:base-
> revision property being set incorrectly, the interleaving revision being
> invisible to bzr clients, and a mangled tree.
>
> For example, I have a checkout of a Subversion branch, from which I made
> a topic branch and modified a file. I merged the topic branch into my
> checkout, and ran 'bzr ci -m "blah blah blah"'. Before my commit
> completed, my co-worker commited a change to another file in the same
> Subversion branch using svn. His commit completes first and is revision
> x, mine completes immediately afterwards and is revision x+1. However,
> my commit x+1 has it's bzr:base-revision property set to x-1 rather than
> x. Subversion revision x doesn't appear in the output from bzr log, and
> the revision's changes are not reflected in the tree.
Does revision x appear in the svn log output ?

Cheers,

Jelmer

Huw Giddens (hgiddens) wrote :

Revision x appears in the svn log output, svn working copies update fine etc.

Huw Giddens (hgiddens) wrote :
Huw Giddens (hgiddens) wrote :

It seems I was a little hasty to say that tweaking bzr:base-revision manually fixes it. Checking out a bound branch after doing this gives me a branch with history that appears correct but that I can't commit to; it complains that my branch is out of date but running bzr up gives me no more revisions.

lem:qt4-trunk % bzr up && bzr ci -v -Derror -m 'Trac #1608'
Tree is up to date at revision 14408.
bzr: ERROR: bzrlib.errors.BzrCommandError: Bound branch BzrBranch7('file:///home/giddens/Source/Terminal/qt4-trunk/') is out of date with master branch SvnBranch('http://host/svn/tux-svn/Terminal/branches/Qt4_trunk').
To commit to master branch, run update and then commit.
You can also pass --local to commit to continue working disconnected.

Traceback (most recent call last):
  File "/home/giddens/Source/bzr/2.0-with-ghost-diffs/bzrlib/commands.py", line 842, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/home/giddens/Source/bzr/2.0-with-ghost-diffs/bzrlib/commands.py", line 1037, in run_bzr
    ret = run(*run_argv)
  File "/home/giddens/Source/bzr/2.0-with-ghost-diffs/bzrlib/commands.py", line 654, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/giddens/Source/bzr/2.0-with-ghost-diffs/bzrlib/builtins.py", line 3072, in run
    raise errors.BzrCommandError(str(e) + "\n"
BzrCommandError: Bound branch BzrBranch7('file:///home/giddens/Source/Terminal/qt4-trunk/') is out of date with master branch SvnBranch('http://host/svn/tux-svn/Terminal/branches/Qt4_trunk').
To commit to master branch, run update and then commit.
You can also pass --local to commit to continue working disconnected.

Yeah, I think the local and remote repository now disagree about the
state of your repository.

bzr-svn should've aborted halfway through pushing when it saw the commit
from the other person and printed a "Out of date" error.

The best workaround at this point is to throw away your local checkout
and create a new checkout - this should have the "correct" history.

Unfortunately this'll be hard to reproduce or test in the testsuite :(

  status triaged
  importance high

Changed in bzr-svn:
importance: Undecided → High
status: New → Triaged
Jelmer Vernooij (jelmer) on 2010-07-31
Changed in bzr-svn:
milestone: none → 1.0.4
Jelmer Vernooij (jelmer) on 2010-08-29
Changed in bzr-svn:
milestone: 1.0.4 → none
Tomasz Gajewski (tomga) wrote :

II think I'm hit by this bug. In bzr log I have a missing revision made with native svn client which was committed during push of some changesets.

This revision is ignored even in new checkouts from this repository. So this seems to be different from what is written by Jelmer made on 2010-02-03.

Maybe we should treat this as two separate issues:

1. allowing such "missing" changesets
2. depending on wrong information in svn repository that leads to broken checkouts after starting from scratch.

Is there a known procedure to fix svn repository to make bzr checkout work properly?

Tomasz Gajewski (tomga) wrote :

Forgot to add version information:
I have debian testing/unstable with:

ii bzr 2.2.0-1 easy to use distributed version control system
ii bzr-svn 1.0.4-1 Bazaar plugin providing Subversion integration
ii libsvn1 1.6.12dfsg-1 Shared libraries used by Subversion
ii subversion 1.6.12dfsg-1 Advanced version control system
ii subversion-tools 1.6.12dfsg-1 Assorted tools related to Subversion

Tomasz Gajewski (tomga) wrote :

I have read instructions from bug #587819 and I think that my issue is a little different.

Normally I use bzr checkout from svn and than branch it with bzr. I work on some features in branch and push changes in series. Svn commit not available later in history was checked in during commiting sequence of changesets. So in my case value for 'bzr:base-revision' for first changeset seems to be ok (contains svn-v4:<uuid>:trunk:<svn-rev - 1>), next there is svn changeset without any value for 'bzr:base-revision' and next changeset from bzr that has the form <mail>-<datetime>-<some_id>.

Do I correctly assume that it is different issue and if so should I create another bug entry for this?

Billie Cleek (cleekbi) wrote :

I have to echo Tomasz Gajewski's assessment. After this happened to me, I was able to checkout to a new repository, but unable to commit. Any attempts to commit resulted in the error that Huw Giddens noted, "it complains that my branch is out of date but running bzr up gives me no more revisions." I even dumped the subversion repository, removed all of my revisions that had been committed from bzr-svn from the dump and then loaded the dump file into a brand new repository. After clearing my bzr-svn cache and removing the subversion repository entry from subversion.conf, any attempts to commit changes using bzr-svn resulted in the error about the branch being out of date, but update did not bring in any more revisions. Interestingly, viewing the log using TortoiseSVN or svn.exe showed that the revisions I had removed were in fact removed, but 'bzr log' would show the log messages for the removed revisions and the file change list for the revision after the revision that had been removed.

Jelmer Vernooij (jelmer) wrote :

Tomasz, as far as I can tell that is the same issue.

Jelmer Vernooij (jelmer) on 2011-03-09
Changed in bzr-svn:
status: Triaged → In Progress
assignee: nobody → Jelmer Vernooij (jelmer)
Jelmer Vernooij (jelmer) on 2011-03-09
Changed in bzr-svn:
milestone: none → 1.1.0
Jelmer Vernooij (jelmer) on 2011-03-10
Changed in bzr-svn:
status: In Progress → Fix Committed
Jelmer Vernooij (jelmer) on 2011-08-26
Changed in bzr-svn:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers