revision missing from repo, causes merge, rebase, etc. to fail

Here is a more minimal demonstration of the problem"

$ echo 'hello' > testfile.txt
$ bzr add testfile.txt
adding testfile.txt
$ bzr commit -m"testing to see if the repository is totally screwed up"
HTTPS services.firedoglake.com, Realm: 'bzr' username: john
HTTPS <email address hidden>, Realm: 'bzr' password:
Committing to: https+webdav://<my domain>/bzr/trunk/
added testfile.txt
bzr: ERROR: No such file: 'https://<my domain>/bzr/.bzr/repository/upload/c0wn77ohl71bfmhsmjwr.pack.tmp.1269708501.565911055.8891.1592856315'

Note that that is on a fresh checkout of my branch, not in an enclosing repo, but standalone. so there is no local "cruft".

Let's start by investigating this particular case

Hi John,

The https message:

> bzr: ERROR: No such file: 'https://<my domain>/bzr/.bzr/repository/upload/c0wn77ohl71bfmhsmjwr.pack.tmp.1269708501.565911055.8891.1592856315'

looks like quite a different problem and quite surprising. If you have the traceback for that can you please paste it? What kind of server setup are you using there?

As far as the missing revision bit: can you describe anything about the manipulations you were doing to this repository around the time the problem first appeared? Were you perhaps moving or copying repository directories around?

This question was expired because it remained in the 'Needs information' state without activity for the last 15 days.

Hi Martin.

Thank you for the attention that you have given to this bug.

I am very frustrated with myself for not having engaged with you back when you engaged with me. My travel and work schedule made it essentially impossible for me to do so.

Below I have pasted some comments from someone who helped me from #bazaar, Max Bowsher. Hopefully these comment will be useful to you. If you need any further information from me, let me know.

----
Your problems all stem from trunk revno 1906,
revid:<email address hidden>, "templates for
firedoglake.com timelines", which is recorded as being a merge of the
first four revisions of the myfdl branch into trunk, though it
absolutely is not.

Because the revision containing the initial addition of the myfdl
directory is *recorded* as being merged to trunk, but without addition
actually taking place, it is as if the initial addition was merged to
trunk, and then they myfdl subtree was deleted on trunk.

When you come to merge trunk into myfdl, one of the things included in
the merge is the effective deletion of myfdl, but since many more things
have been added within myfdl on the branch, you get conflicts galore.

To get out of this mess, you need to merge the revision containing the
merge-but-effective-delete of the myfdl directory, omitting the actual
deletion.

It's possible to do this just by:
bzr merge ../trunk
bzr revert myfdl
(resolve other conflicts)
bzr commit

However, I think it's more self explanatory why this is the right thing
to do if you do it in three stages:

Phase 1: Merge everything *before* the problem revision:
bzr merge -r 1905 ../trunk
(resolve conflict)
bzr commit -m "Merge up to r1905 from trunk."

Phase 2: Merge *just* the semi-bogus revision
bzr merge -r 1906 ../trunk
bzr revert myfdl
bzr commit -m "Merge r1906 from trunk."

(You can verify easily that the actual changes r1906 introduced to trunk
are just to three files not inside myfdl, and thus the revert is in fact
completely safe.)

Phase 3: Merge the rest
bzr merge ../trunk
(resolve conflicts)
bzr commit -m "Merge trunk."

Max.

You know what -- It's been so long since I was thinking of this, I'm not even sure if the above was regarding the same bug.

I have failed at being a constructive open source community member. I hang my head in shame.

If I can put something more constructive together, I'll make a new bug or open this one.

Thanks,
John

On 12 May 2010 21:06, John Bachir <email address hidden> wrote:
> I have failed at being a constructive open source community member. I
> hang my head in shame.

Don't take it so hard.

--
Martin <http://launchpad.net/~mbp/>

hah -- I was going for a bit of comical exaggeration there, but thanks :)