Update: Re: bzr 0.6 commit problem: parent_id {blah} not in inventory

[Andrew S. Townley]

On Thu, 2005-11-03 at 10:32, John Arbash Meinel wrote:
> Well, part of that I just wanted you to do for testing. You can actually
> "roll-back"[*] a commit, either using my uncommit plugin, or even
> simpler by just editing the .bzr/revision-history file, and removing the
> last entry.

Interesting...

> As far as changing the default commit from local to global, I can write
> you a plugin that always supplies "." to the standard commit (if nothing
> else has been supplied).

Yeah, I hadn't thought of that.  It isn't that big of a deal.  I was
thinking more in terms of what bzr thought it needed to do (by looking
at the whole tree) rather than just doing what it was told (no, I don't
care about the rest of the tree, pay attention to only this
directory/file/whatever).  Your plug-in really wouldn't alter the
behavior, and, admittedly, I was only trying to think of ways around the
bug that I hit. :)

Actually, the one thing about the "whole tree" approach to all the
commands that seems a bit strange to me is that no matter where you are
in the tree, you get information from the top.  If your tree isn't
complex, this may not be that big of a deal, but with something like
Java source, you've loads of directories and the CVS approach to only
telling you about the status of the current directory is a big help in
filtering the data you actually see to data you can do something about
from where you are on the filesystem.  Maybe for everyone using IDEs,
this isn't a big deal at all, but my IDE is Gnome, about 5-8 gnome
terminals (one per major package root, for example), vim and ant, so
maybe it's just a personal problem... :)


> Is this a public project, so that I could see the actual changes? If
> not, we'll try to keep helping.

Unfortunately, no.  Although, one of the things I noticed in the
inventory file as I was poking around was that there was a file which
seemed to be out of order.  Without looking into the design much, it
seems like each <directory...> element is supposed to contain nested
elements of all the files and directories which are its children,
complete with back references to the parent item (I'm assuming these are
only necessary because of the way you're processing the file as text
rather than XML because it is possible to determine this from the
structure, but that's another discussion as well.  I think I understand
why you're doing what you're doing).

Anyway, there was one which somehow got out of order and appeared with a
different parent than the element in which it was nested.  Not sure if
this is part of the problem or not.  Based on my 2s look at the
inventory.py file when I added my print statement, it looks like the
file is processed sequentially, so it was further down than the entry
that was having issues.  Probably something else.

For the tag support from Gustavo, I remembered reading about it with
some interest.  I agree that the commit is a bit awkward, and I would
also agree that in practical use with a lot of tags, you do need them to
be separate from the tree so that they can provide an external index
(slice) through a set of revisions.

I'll have a look at it when I get a chance, but at the moment, I'm
trying to implement some stuff to get my project to a point where I can
disappear on the 14th of December until the end of January, so I'm
trying to manage my distractions... :)

Still, I'm very interested in getting bzr into something that I might be
able to actually roll out to our project team of 20+ developers and then
publicly host a repository of some of the work which is open source.  At
the moment, we're using CVS for this, but I'm convinced distributed
version control is the way to go.  At the moment, bzr is ahead because
it was easier to install than monotone (but I still need to give that a
fair chance), but, again, I wanted to focus on doing real work rather
than testing the VCS due to my deadline.  So, I will make an effort to
check it out.  Just out of curiosity, is it compatible with the 0.6
storage?

Again, thanks for all the help trying to solve the problem.  If you
still can't reproduce the problem, I can probably work something out to
at least let you look at parts of the .bzr directory, but the
repository's about 71M because it contains some large documents in
addition to the source.  The .bzr directory is 38M, but again, that's
because of the docs.

Cheers,
ast

***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************