kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/30/2010 1:15 PM, Dick Hollenbeck wrote:
> On 06/30/2010 11:47 AM, Dick Hollenbeck wrote:
>> On 06/30/2010 10:09 AM, Wayne Stambaugh wrote:
>>   
>>> Dick,
>>>
>>> I just got the notification that your latest commit to the testing
>>> branch had removed last five revisions.  I just checked and sure enough
>>> the last five commits got clobbered.  It was at revision 2408 before you
>>> first commit which went in as 2404.  This commit should have been
>>> revision 2409.  Something has gone terribly wrong here.
>>>
>>> Wayne
>>>   
>>>     
>> Sorry, I am not sure what I did wrong, or even how to fix it.
>>
>> But I am looking into it now.
>>
>> It is actually quite alarming that anything could be done to clobber
>> more than the most recent commit.  (BZR supports the uncommit command,
>> so I can understand losing one commit.)  I am not clear on how 5
>> revisions can vanish, even with user error.
>>
>>
>> Dick
>>   
> 
> 
> First before anyone panics, please see if the actual contents of changes
> have been lost, ignoring revision numbers.

Everything is in tact.  I did a diff against revision 2408.

> 
> I have a full command line history intact, so I can tell accurately what
> I did.  Here it is:
> 
> 1) $ bzr status  # make sure I had nothing uncommited
> 
> 2) $ bzr merge   # grab changes from lp:kicad (=testing)

Merge is where the testing repo information is getting changed.  Using
merge took the testing repo revisions 2404-2408 and made sub-branch
2403.1.1-2403.1.5 in your local branch.  Then when you committed your
branch, the testing repo revision became your branch version.  Using bzr
update would have preserved the previous commit information.  In effect,
the testing branch is now a sub-branch of your local branch.

> 
> 3) $ bzr diff   # show all changes
> 
> 4) $ bzr log eeschema/dialog_edit_component_in_lib.cpp
> 
> 5) $ bzr ci -m mainline-merges
> 
> 6) @note: mark this spot for note below
> 
> 7) $ bzr status
> 8) $ jedit eeschema/dialog_edit_component_in_schematic.cpp
> 9) $ bzr ci -m "fix comment to proper English"
> 10) $ bzr push
> 
> 
> At the @note I did an edit and a revert on one *fbp.cpp file, explicitly
> provided on command line, after I remembered that wxformbuilder edits
> this file.
> 
> What is a better way for me to be using bzr?

I don't know if it is a better way, but my understanding of the bzr
merge command is that it does a three way merge where update brings your
local branch up to date (two way merge?) with the repo it is linked to.
 I would think you would only want to use merge to merge a different
branch derived from the testing branch with your local branch.  For
example, say I publish my branch for developing the new component
library file format and you decide you want to help so you merge my
branch with you local branch.  Then we both make commits to the new
library file format branch until it is ready to move into the testing
branch.  Then one of us commits the changes to the testing branch.  This
commit revision will have all of the commits to the new library file
format branch as a sub-branch.  The best way to see what is going on is
to use bzr-explorer and look a the log and you can see what happened.

Wayne

> 
> 
> Dick
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>