----- Original Message -----
> From: Joel Holdsworth <j...@airwebreathe.org.uk>
> To: kicad-developers@lists.launchpad.net
> Cc:
> Sent: Wednesday, February 5, 2014 12:04 AM
> Subject: Re: [Kicad-developers] Revisiting the Git decision
>
> Hi All,
>
> Thank you all for taking the time to respond to my original e-mail. It
> seems to me that whatever the outcome this discussion it is well worth
> having.
>
>
[snip]
>
> Let me ask - do you think Bazaar has a bright future at this point?
>
I doubt it, but for the moment it works and Canonical don't seem so
concerned either. Some of the software I use has barely changed in 30
years, some haven't changed at all for almost 40 years now, but that
means nothing other than it hasn't changed, not that it's somehow
necessary to abandon it.
> My fear is that this is just going to get worse and worse, and so
> after some years the project will have no option but to move. - which
> should be doable at that time, but in the meantime you will have
> missed out on all the benefits of using a more widely known system.
>
I'd wait to see if launchpad migrate. Remember we have to move the source,
history, and bug tracking info.
[snip]
> There are a couple of things I'd like to have also. Are these things
> possible? ....
>
> Creating a branch involves creating a whole copy of the source tree,
> and thus the rebuild time. Therefore branching is not a cheap
> operation, which is a shame because it's nice to be able to create 5
> branches - slowly iterating towards the perfect patch set. So I would
> love to be able to do in-place branching - is this possible with bzr?
>
No. And although in-place branching is possible with git, it is not
necessarily more convenient; this is just one situation where there's
no clear winner between techniques used. Unless you're frequently
updating and rebuilding many branches, you don't lose all that much time.
Does the build system work quicker with the in-place branch? I can't
remember the last time I branched a large git project.
> Also, when I work on an experimental branch I tend to tidy it up with
> git rebase: splitting commits up, and squashing them together,
> reordering them, renaming them - generally tidying the patch set, and
> removing extraneous guff before submission. Is such a workflow
> possible? I used the rewrite plugin, and it seemed to be a rather
> unloved way of working in bazaar world.
>
Rather than a rebase I just pull in the latest changes and ensure that
they merge correctly. Same effect. When code is likely to change
frequently this is the way you're forced to work in git as well, otherwise
the rebase will be painful. As for smaller commits etc, that just takes
some planning. If feature X requires some serious modifications to other
code before work can really proceed, then work on those code changes
first and introduce them in smaller steps if possible - this is nothing new.
> Also, does bazaar have anything like git add -p, where you go through
> your changes selecting which parts of your work you want to go into
> this commit?
>
I don't think so, but doing the equivalent is a simple matter of planning.
> Coincidently I used to be an Inkscape contributor myself many years
> ago - back in the SVN days. At that time SVN was open access -
> basically to anyone who would ask, - no review process or anything.
> The result of having this committer free-for-all was that the code was
> in really bad shape: really messy, and unstable. This got so bad that
> is basically became a roadblock to further development to the point
> where they had to spend the last couple of years on a major tidying
> effort as a result.
>
Yes, but that's not currently an issue with the KiCad project. If anything
we need more long-term contributing programmers who can help check patches.
- Cirilo
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
