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

Thu Nov 3 10:32:08 GMT 2005

Andrew S. Townley wrote:
> Hi John,
> 
> Thanks for your help.  Details below.
> 
> On Wed, 2005-11-02 at 19:30, John Arbash Meinel wrote:
> 
> 
>>Before you get too far, the inventory.weave file is for *committed*
>>revisions. So naturally it should still have the old value, because that
>>is the history.
> 
> 
> That makes sense, I was thinking it must be something like that due to
> the content of the other *.weave files in the directory.
> 
> 
>>Can you meet on IRC? That is a faster turnaround than posting to the
>>mailing list and waiting for a reply.
>>#bzr or irc.freenode.net
> 
> 
> Yeah, I probably can get an environment set up.  Most of the time, the
> network connections I have won't allow it.  There's also the 6hr time
> difference :)
> 

Well, you might find that there are people on IRC kind of around the
clock. Right now the main developers are in Canada at Ubuntu Below Zero,
but at least a couple of them are in Australia, while I'm in the US,
Aaron is in Canada. I'm not sure of anyone else's location, but in
general, we have quite a few time zones covered :)

> 
>>In the meantime, can you go to the root directory, and just type:
>>
>>bzr status
>>
>>To see what it says. If it is happy, commit should be happy.
> 
> 
> Yeah.  Did that.  It says it's fine.
> 
> 
>>I'm wondering, are you trying to do a partial commit? Running something
>>like:
>>	bzr commit -m 'something' .
>>It might be that it is only grabbing half of the change, and missing the
>>rest.
> 
> 
> That's exactly what I was trying to do.  I almost got out the big hammer
> of a global commit to see what that would do, but I had a bunch of
> somewhat unrelated changes that I wanted separate commit messages for,
> so, for me (probably after 10+ years of CVS conditioning) I would really
> love a way to change the default commit mode from global to local, but
> that's another conversation that I already raised before. :)

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.

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).

> 
> Based on what you said, I did a global commit and that worked, however I
> would hope that this is something that isn't always required when you
> move files around.  The other thing that I thought was strange was that
> I was originally trying to commit the moved file alone as a single
> commit message with:  bzr commit -m "Moved file because of xyz"
> MovedFile.java, but that didn't work.  I then tried to commit the rest
> of the files in case I did have to commit from the top, but then bzr
> wouldn't let me commit anything else, no matter where in the tree I was.

I don't know why it wouldn't let you do a partial commit after having
moved a file. I agree that it should, though probably we just haven't
worked out the bugs of that particular use case.

> 
> To me, this doesn't make sense, and it also encourages what I would
> consider (and I know this might start an argument, but...) "sloppy" VCS
> usage by applying the same message to a bunch of files.  I have
> personally found that when this is done, the commit logs don't really
> tell you much, and if you really want to find out what happened, you end
> up doing diffs against the tree based on various dates.  Therefore, my
> personal discipline and the discipline that I require from my teams is
> that log messages describe the rationale for the change for each
> individual file.  Of course, if you have to refactor a name or something
> in multiple places, a multiple file commit with the same message is
> perfectly valid.  However, normally, I have to make several, only
> tangentially related, changes as I add functionality because I also
> don't want to check in things that don't work into the repository.

Sure, each logical change should be a separate commit. And it is fully
in the design for partial commits to be supported.
There is also the theory that you should only commit what has actually
been tested, and partial commits don't do that.

Personally, I try and follow a dev tree versus mainline approach. I try
to commit every small change in my dev tree, even if it means the tree
is broken from time to time. But on the mainline tree, every revision
should pass the test suite.

> 
> Sorry, that got a bit long, but the sort version is that I believe bzr
> (or any other VCS) should always allow atomic commits at the single file
> level, regardless of what happened in the tree.  This isn't the first
> time I've hit a similar issue in the last few days, but I didn't have as
> many changes pending, so it wasn't that big of deal.  Yesterday, I had
> refactored some bits, and added some significant new bits, all of which
> logically hung together as a single unit of functionality.  That still
> doesn't mean that I believe they should have all had a blanket log
> message.
> 
> Is this behavior what was intended with bzr?

I think you just ran into a bug. I'll see if I can reproduce it on my
end. So far I have not been able to.
I've been able to rename things, and just commit those changes, even
though there were other changes in my tree.

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

> 
> Other than that, I've been quite happy with it.  The transition from CVS
> has been reasonably straightforward, although I got caught by
> accidentally doing a bzr rm, but that was easy enough to undo; and I
> think that revert should be one of the options that shows up in the
> abbreviated help.  Reason being that if you've made some incompatible
> changes to try and diagnose a problem, but don't want to keep them,
> sometimes it's easier to blow away the file and get it back from the VCS
> than to undo the changes that were never intended to be committed.

Actually, I would agree that revert should be in the short help. There
was a small bug with added files getting fully removed, rather than just
being marked as not-added. But I'm not sure the state of that right now.

> 
> Thanks for all the efforts, and keep up the good work.
> 
> Cheers,
> 
> ast

John
=:->

[*] By roll-back, all of the actual changes are still in the
.bzr/weaves, but the branch itself no longer thinks that it has been
committed. So your changes will show up, and you can go back and do a
partial commit.
It actually is a way that you can support quilt-like behavior. Where you
try something, and commit it, then rollback refactor it, and commit
again, etc, until you get what you want.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051103/a1086a7b/attachment.pgp 