Bloodhound / Trac Approach
DavidRichards
I think it prudent to modify our approach here.
Ethan Jucovy actually suggested that:
"core patches could be submitted upstream and
locally maintained in a Mercurial patch queue or a Git fork with a
very
branchy workflow which is used as the underlying dependency for
Bloodhound trunk development, while the rest of the project proceeds
in an
Apache Subversion repository."
I think this approach makes sense. Effectively forking the core in
Edgwall and using that as the upstream into Apache Bloodhound.
I think this is workable from our perspective initially. We may need
to take pieces into Apache over time but we will just have to wait and
see.
Overall the debate was good, thank you to everyone that participated
osimons
Ethan Jucovy
Gary
> 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?
Cheers,
Gary
--
Gary Martin
Lead Developer
WANdisco, Inc.
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Everything you need to deploy Subversion in the Enterprise
http://www.wandisco.com/subversion
Subversion community
http://www.svnforum.org
Felix Schwarz
Am 05.01.2012 12:56, schrieb Gary:
> 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?
There is also a bitbucket mirror:
http://bitbucket.org/edgewall/trac
http://trac.edgewall.org/wiki/BitBucket
(oh no, Bitbucket is down for me...)
Personally I prefer hg but I got used to git as well.
fs
osimons
> Am 05.01.2012 12:56, schrieb Gary:
>
> > 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?
>
>
> Personally I prefer hg but I got used to git as well.
>
> fs
I prefer fork or patch queue at Bitbucket too.
:::simon
Chris Nelson
I'm a git fan but I'll adapt.
--
Christopher Nelson, Software Engineering Manager
SIXNET - Solutions for Your Industrial Networking Challenges
331 Ushers Road, Ballston Lake, NY 12019
Tel: +1.518.877.5173, Fax: +1.518.877.8346 www.sixnet.com
Dalton Barreto
> I'm a git fan but I'll adapt.
>
Not needed. Bitbucket now rocks git [1]. =)
[1] http://blog.bitbucket.org/2011/10/03/bitbucket-now-rocks-git/
--
Dalton Barreto
http://daltonmatos.com
Olemis Lang
> On Thu, Jan 5, 2012 at 6:56 AM, Gary <gary....@wandisco.com> wrote:
>> Hi everyone,
>>
>
> Hi !
>
>>
>> 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?
>>
>
> ;)
>
> https://www.coderesort.com/u/simon/blog/2011/12/17/bitbucket_patch_queues
> http://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org
>
btw , that's *SIMILAR* to what osimons and I used to do so as to
develop TracXmlRpcPlugin >= 1.0 .
It's a convenient setup for CI as well (I mean to automate CI for the
patch queue(s) , not just the main Trac repos ;)
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Tweet: +1 RT @holdenweb This is insane. Everyone should be fighting
this: Stop American Censorship http://t.co/S9EIkYdk #fb
Follow @olemislc Reply Retweet 23:08 Dec-14
Get this email app!
Get a signature like this. CLICK HERE.
Steffen Hoffmann
Hash: SHA1
Am 05.01.2012 13:41, wrote osimons:
> I prefer fork or patch queue at Bitbucket too.
>
Yes, and often considered easier to start and use for someone already
familiar with SVN too. MQ is very nice. I use it a lot.
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8F04sACgkQ31DJeiZFuHcAAACdGqY4jswMi0mql36gosBxEzws
l6gAn1pjF6TOwZVkNkU53jW3HHcvpkcm
=vWXX
-----END PGP SIGNATURE-----
Christian Boos
> 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
Peter Suter
> 1. fix/feature branches [...] with Mercurial (assuming you're using bookmarks
I've not used bookmarks much before. Are they supported in Trac's
mercurial plugin? I pushed a bookmark[1] now to my Trac clone[2] but
can't see it anywhere in the source browser.
[1] T8925_TitleIndexMacro
[2] trac.edgewall.org/browser/psuter
> Voila ;-) If people find these advices useful (especially 1.),
> I'll integrate them in the Wiki.
+1
Peter
Christian Boos
> On 06.01.2012 16:28, Christian Boos wrote:
>> 1. fix/feature branches [...] with Mercurial (assuming you're using
>> bookmarks
>
> I've not used bookmarks much before. Are they supported in Trac's
> mercurial plugin? I pushed a bookmark[1] now to my Trac clone[2] but
> can't see it anywhere in the source browser.
No, it's not yet supported.
Should be relatively easy to add in the quickjump menu, under a new
bookmark topic. To be visible as "annotations" to changesets (in the
timeline for example), the easy path would be to pretend they are tags
(like `hg id` does)... and in a sense, it's a kind of moving tag.
>
> [1] T8925_TitleIndexMacro
Btw, glad you reworked this topic! I had some pending changes I was
never satisfied enough to publish, so it's nice to see some fresh ideas
there.
-- Christian
Peter Suter
> On 1/7/2012 12:28 PM, Peter Suter wrote:
>> On 06.01.2012 16:28, Christian Boos wrote:
>
> No, it's not yet supported.
>
> Should be relatively easy to add in the quickjump menu, under a new
> bookmark topic. To be visible as "annotations" to changesets (in the
> timeline for example), the easy path would be to pretend they are tags
> (like `hg id` does)... and in a sense, it's a kind of moving tag.
Sounds good. TracLinks would also be nice. (cset: etc. doesn't
understand tag, branch nor bookmark names, right? At least for
non-default repositories.)
>> [1] T8925_TitleIndexMacro
>
> Btw, glad you reworked this topic! I had some pending changes I was
> never satisfied enough to publish, so it's nice to see some fresh ideas
> there.
>
> -- Christian
Getting all the corner cases and feature combinations to work is
trickier than one would think!
Peter
Remy Blank
> 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.
I still don't understand why people keep wanting to rebase instead of
merge. I have been working with Mercurial for years now, and I still
haven't had a valid use case for rebasing. The same applies to MQ, for
that matter.
The only "difficult" operation is showing a diff of the branch against
upstream, as you have to find the last merged revision. But that's
easily solved with a revset expression and an alias (at least with
Mercurial).
But maybe it's just me...
-- Remy
Christian Boos
> Christian Boos wrote:
>> 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.
>
> I still don't understand why people keep wanting to rebase instead of
> merge. I have been working with Mercurial for years now, and I still
> haven't had a valid use case for rebasing. The same applies to MQ, for
> that matter.
Well, I had to deal once with such a sequence of original commits
interspersed with merges with upstream and tried to 1)
distinguish inside the merge commits the conflict
resolution (interesting) from the changes brought from
upstream (uninteresting), 2) try to reintegrate some of the
changes back upstream. Neither task was easy with merges, but
would have been with a rebased branch (or a refreshed MQ stack).
Of course, if you simply want to merge the topic branch back in
upstream, then you perhaps don't need to do these intermediate
steps and the only disadvantage would be some extra noise in the
graph, a minor inconvenience.
But it's not what we need to do here. First, we don't have a
DVCS, so in Subversion the only choice left for reintegrating is
between integrating all the changes from the topic branch at once
as a single collapsed changeset, or committing again the
individual changesets from the topic branch one by one. In the
latter case, you'd have to "reverse engineer" the rebase from the
original changesets plus the merge changesets. This is quite
painful, but you have no other choice when you don't want to take
all the changesets of the branch. And even if you'd take all of
them, it's just a nicer thing to do, to reapply the changes with
their original commit log one by one, as smaller changesets are
better for explaining the changes and isolating a regression.
Even if we used a DVCS, the revision graph just looks nicer and
easier to understand if each merged topic branch is itself a
linear one and doesn't contain other merges.
Example:
-- 1 -- 2 -- 3 -- 4 (upstream)
\
-- a -- b -- c (topic)
Simple.
A few merge and modifications later:
-- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 (upstream)
\ \ | \
-- a -- b -- c -- d -- e -- f -- g (topic)
Now you have to find out that that (d) is merge that besides all
the changes from 2, 3, 4 also contains changes which resolved
conflicts between 2 and b, 3 and c... That (e) brought all the
changes from 5 and 6 and nothing more, that (g) again solved a
conflict between 7 and b...
How would you now reintegrate back such a branch on top of
upstream, as a -- b'' -- c' -- f? Frankly, I think you wouldn't
and instead you would just apply diff(7, g) and be done with it,
no?
I much prefer a workflow where it's easy to reintegrate the topic
branch as a sequence of changes.
With a DVCS, if you had done a rebase rather than a merge at the
same reference points as in the above (4, 6 and 7), you'd get the
following graph:
-- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 (upstream)
\ \ \ \
\ \ \ -- a -- b'' -- c' -- f (topic.4)
\ \ \
\ \ -- a -- b' -- c' (topic.3)
\ \
\ -- a -- b' -- c' (topic.2)
\
-- a -- b -- c (topic)
And the final merge would look like:
-- ... -- 5 -- 6 -- 7 ---------------------- 8 (upstream)
\ /
-- a -- b'' -- c' -- f (topic.4)
Note that the intermediate branches topic, topic.2 and topic.3
would still be present in the contributor's repository, but
wouldn't be pushed in the upstream repository.
And finally in Subversion, that would just appear as:
-- ... -- 7 -- a -- b'' -- c' -- f (upstream)
-- Christian
Grzegorz Sobanski
[...]
> But it's not what we need to do here. First, we don't have a
> DVCS, so in Subversion the only choice left for reintegrating is
Maybe it is a good time to drop SVN as main repository for trac
and move fully to DVCS?
--
silk
Remy Blank
> But it's not what we need to do here. First, we don't have a
> DVCS, so in Subversion the only choice left for reintegrating is
> between integrating all the changes from the topic branch at once
> as a single collapsed changeset, or committing again the
> individual changesets from the topic branch one by one.
I see no reason to do the latter. You use the DVCS as your sandbox, and
you apply a complete *feature* back to SVN.
> Even if we used a DVCS, the revision graph just looks nicer and
> easier to understand if each merged topic branch is itself a
> linear one and doesn't contain other merges.
Why do you care what the revision graph looks like? I don't. But even if
I did...
> -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 (upstream)
> \ \ | \
> -- a -- b -- c -- d -- e -- f -- g (topic)
or...
> -- 1 -- 2 -- 3 -- 4 -- 5 -- 6 -- 7 (upstream)
> \ \ \ \
> \ \ \ -- a -- b'' -- c' -- f (topic.4)
> \ \ \
> \ \ -- a -- b' -- c' (topic.3)
> \ \
> \ -- a -- b' -- c' (topic.2)
> \
> -- a -- b -- c (topic)
... I certainly find the former more intuitive. It says exactly what I
did: work on a feature, merge new stuff from upstream, work some more,
and finally apply the patch.
> And the final merge would look like:
>
> -- ... -- 5 -- 6 -- 7 ---------------------- 8 (upstream)
> \ /
> -- a -- b'' -- c' -- f (topic.4)
That's only the case if you remove the stale branches, meaning you lose
history. You're mutating it anyway by rebasing, so it's not that
important anymore.
I guess it boils down to choosing between having a linear revision graph
and mutating history, or having a graph that reflects how the work was
actually done, and keeping history intact.
I prefer the latter. So yes, I guess it's just me :)
-- Remy
Steffen Hoffmann
Hash: SHA1
Am 07.01.2012 19:35, wrote Remy Blank:
> I guess it boils down to choosing between having a linear revision graph
> and mutating history, or having a graph that reflects how the work was
> actually done, and keeping history intact.
Huh, "mutating history" sounds evil, right? ;-) But it's essential to
achieve functionality I use everyday, like hgsubversion. Doing changes
and commits offline, pushing to (trac-hacks) SVN later and getting local
repo copy "corrected" afterwards to reflect the official repos's state,
this is just great.
> I prefer the latter. So yes, I guess it's just me :)
Sure, all this development work-flow is largely a matter of personal
preference, what is most familiar and intuitive to you, ...
I don't mind using SVN for the official repo, because it doesn't limit
you anymore to use something else locally. Anyway, interesting to listen
to different recommendations/suggestions for structuring development
work, to make up my mind.
Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk8ImBcACgkQ31DJeiZFuHetIQCgzlWaRf0Dc3gbq5XXkVkCeGCX
1zwAoL9SrkaBzRNNfemQ9adjFfVSke49
=4Hm3
-----END PGP SIGNATURE-----
Christian Boos
Well, then we would argue endlessly about which one to use ;-)
I think the current approach is not so bad, as we have a
reference in Subversion and mirrors in both git and
Mercurial. Besides the external mirrors, we even have "in-house"
work repositories for the Trac committers, which are included as
repositories in t.e.o. We might do that for git as well.
So until we get really a ton more activity and it would become
obvious that staying with svn would slow us down, I don't see the
urge to move.
If future versions of Trac would greatly improve the support for
DVCS specific workflows, then of course it would become a
different matter...
-- Christian
Olemis Lang
>
> Christian Boos wrote:
> > 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.
>
> I still don't understand why people keep wanting to rebase instead of
> merge. I have been working with Mercurial for years now, and I still
> haven't had a valid use case for rebasing. The same applies to MQ, for
> that matter.
>
fwiw , I second that .
fwiw , I'd really prefer Hg MQ rather than git .
--
Regards,
Olemis
Facebook => http://www.facebook.com/olemis
Twitter => http://www.twitter.com/olemislc (@olemislc)
Blog ES => http://simelo-es.blogspot.com
Blog EN => http://simelo-en.blogspot.com
Quora => http://www.quora.com/olemis
Youtube => http://youtube.com/user/greatsoftw
Featured article : El SPDY de Google no es tan malo como el Internet
Explorer (IMO)
http://feedproxy.google.com/~r/simelo-news/~3/Uu6Ez9Qc5vQ/el-spdy-de-google-no-es-tan-malo-como.html
Tweet: El SPDY de #Google no es tan malo como el Internet Explorer
(IMO) http://t.co/AqNoHXFj #Simelo #blog #fb #windows
Follow @olemislc Reply Retweet 13:22 Jan-05
Chris Nelson
> On Sat, Jan 7, 2012 at 9:57 AM, Remy Blank<remy....@pobox.com> wrote:
>>
>> Christian Boos wrote:
>>> 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.
>>
>> I still don't understand why people keep wanting to rebase instead of
>> merge. I have been working with Mercurial for years now, and I still
>> haven't had a valid use case for rebasing. The same applies to MQ, for
>> that matter.
If I clone a repo with a common branch and am doing some development on
it when someone else updates that branch in the central/shared repo, my
changes look cleaner when checked in if I rebase locally rather than
merge. To merge, I have to push *my* branch to the central/shared repo.
We find that when we do that, we end up with a dizzying number of
branches. It is admittedly a site/personal preference.