kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #10546
Re: fyi extra changes in r4203
-
To:
kicad-developers@xxxxxxxxxxxxxxxxxxx
-
From:
Dick Hollenbeck <dick@xxxxxxxxxxx>
-
Date:
Mon, 10 Jun 2013 08:06:12 -0500
-
In-reply-to:
<CAAPegz0KfwqcKJ-SU5R7=U1D5guGt3hKWJhLMvGfOC3qgGN0vQ@mail.gmail.com>
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
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
Follow ups
References