kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

This workflow makes a lot of sense to me. I have a lot of experience with
vcs but I still can't fit bzr into  the right places in my mind to match up
with anything I've used before.

If you had patches in a series, like several in a row, you'd keep the same
branch, generate diff, commit make changes, generate diff, commit and
repeat and then blow away the directory when the feature was done?

Chris



On Mon, Jun 10, 2013 at 9:06 AM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> On 06/09/2013 03:24 PM, Chris Morgan wrote:
> >
> http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/revision/4203
> >
> > Spotted the extra changes to HOW_TO_CONTRIBUTE.txt when trying to merge
> up to the latest
> > kicad here as it caused a conflict.
> >
> > Chris
>
>
> With bzr, you are advised to keep as a minimum a branch which is kept as a
> "checkout" of
> "testing".  This "checkout" is basically a mirror of whats in testing at
> launchpad.  I
> actually name the dir of the branch "testing.checkout".  In addition to
> this, there can be
> other branches that you maintain for various durations, which start out as
> copies of
> testing.checkout.  But your life is easier with a "readonly" checkout.
>
>
> $ bzr co lp:kicad testing.checkout
>
> make a copy of testing.checkout called mywork:
>
> $ bzr branch testing.checkout mywork
>
> Now "mywork" is a copy of testing.checkout.  It can be short lived.  To
> delete it, on linux:
>
> $ rm -rf mywork
>
> Do this about 2-3 times, to see how fast it is, don't be afraid of doing
> it.
> $ bzr branch testing.checkout mywork
> $ rm -rf mywork
>
>
>
> You can always go see whats new on launchpad with:
>
> $ cd testing.checkout
> $ bzr up
>
>
> One can argue that for someone not allowed to commit to testing, that a
> testing.checkout
> branch should remain a readonly mirror of launchpad.  And any work you
> want to do should
> be done in a copy of it, like "mywork" above.
>
> You can make edits in mywork.
>
> $ cd mywork
> $ bzr st
>
> shows what's changed.
>
> $ bzr diff > /tmp/my.patch
>
> generates a patch.  How easy is that?
>
> You can always get an update to testing.checkout:
>
> $ cd testing.checkout
> $ bzr up
>
> And start again with another task:
>
> $ cd ..
> $ bzr branch testing.checkout task2
> $ cd task2
>
> edit...
>
> $ bzr add newfiles...
> $ bzr rm oldfiles...
>
>
> $ bzr diff > /tmp/task2.patch
>
> There is rarely any need to merge testing.checkout into your own branch if
> you keep the
> lifetime of your branch short and only for generating patches.  If you
> keep a long term
> branch, this become more demanding of your knowledge of bzr.
>
>
> 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
>