On 1/5/2012 12:56 PM, Gary wrote:
> Hi everyone,
>
>> Thanks David. I'm looking forward to seeing how Bloodhound progresses.
>>
>> -Ethan
>
> Obviously I am looking forward to this too! Thanks for all the views
> expressed about this.
>
> To get things moving a little I would like to check if there are any
> preferences for where we branch or fork to the BSD licensed Bloodhound
> core code. As previously noted, Ethan's suggestions were a Mercurial
> patch queue or a Git fork. I have spotted the mirror of Trac on github
> which might be a relatively easy route to work from. Is there anything
> else that would be preferred?
>
We can deal with both. My personal preference would be git, these
days.
In any case, the following generic advice should apply:
- we prefer series of fixes or features focused on one topic
(if there are some clean-ups or unrelated changes done while
working on the topic, then at least split those changes in a
separate changeset)
- clearly indicate the purpose of the branch in its name (see
suggestions later) and fork these branches from the relevant
upstream branch (0.12-stable or trunk)
- be sure to follow the general code contributions guidelines
(http://trac.edgewall.org/wiki/HowToContribute#CodeContributions)
Now some further advices you may want to follow or not...
Actually, I think you may end up with 3 kind of branches:
1. fix/feature branches; be sure to relate this to a ticket number
(e.g. T123 for a ticket on t.e.o, issue123 for an issue in
your github if you use the tracker there, BH123 for the future
Apache-hosted Bloodhound instance?)
Example name: fix-T10485-image-unicode-bug
These branches are best kept linear, for easier integration
upstream. If after a while, the changes don't apply anymore
on latest code from upstream, then you should rather rebase
the changes instead of merging with upstream, as it's more
difficult to examine and reintegrate a branch if it contains
merge changesets.
Note that rather than rebasing the branch itself, you should
create a "rebasing branch", i.e. leave the original branch
alone and create a new rebased one with a related name which
shows clearly that it's a rebased branch
(e.g. in this case fix-T10485-image-unicode-bug.2)
This approach has the following advantages:
- the previous branch is not modified, so if anything else
depends on it (possibly someone somewhere clone it!)
there will be no surprises downstream
- it's easy to //compare// the two versions of the branches
to see what was has changed at the occasion of the rebase
Btw, the very same procedure can be used for a "second
version" of the branch, for example if after review and
discussion, it's easier to actually rework some of the changes
rather than to add more changes to take the feedback into
account.
In practice, creating such a "rebasing branch" is very easy
with git:
{{{
$ git checkout -b fix-T10485-image-unicode-bug.2
fix-T10485-image-unicode-bug
$ git rebase trunk fix-T10485-image-unicode-bug.2
}}}
And with Mercurial (assuming you're using bookmarks - which you
should, as in Mercurial, branches are best used for naming the
maintenance branches):
{{{
$ hg rebase -b fix_T10485_image_unicode_bug -d trunk --keep
$ hg bookmark fix_T10485_image_unicode_bug.2
}}}
(for hg, I use '_' in the bookmark names, as '-' tends to
recognized as a revset operator...)
2. Throw-away integration branches (a.k.a. "next")
You may want to use volatile branches where you test
integration of several new features. Typically a bleeding
edge version you'd use for testing all the topic branches
together.
From time to time, the `next` branch is wiped out
and recreated from the latest maintenance branch,
then all the pending feature and fix branches
are merged in.
See http://progit.org/book/ch5-3.html#largemerging_workflows
in the ProGit book.
3. Long term integration branches ("bloodhound" branch?)
This is where the diverging changes are maintained (e.g. a
feature branch which didn't get accepted upstream but is
nevertheless deemed important for you to keep) and in which
the changes from upstream are regularly merged in. That
branch will never be rebased and will only ever see merges.
Voila ;-) If people find these advices useful (especially 1.),
I'll integrate them in the Wiki.
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
