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

[Andrew S. Townley]

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

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

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.

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.

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?

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.

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

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