One concern I have with moving to Git before Release 3.0 is the tension
between really thinking through the Git move and getting 3.0 out quickly.
On 9/22/2015 7:23 AM, Greg Trasuk wrote:
Apache’s Git support is just fine, and includes the ability to accept
pull requests from Github, in a way that suits our need to ensure
code provenance. The River Container work that I did was in the Git
repository
https://git-wip-us.apache.org/repos/asf/river-container.git.
I’m all for switching to git, but we need to actually discuss it and
work out the desired workflow and project structure. For instance,
git doesn’t really encourage long-lived branches in a repository.
So, should we have separate repositories for the 2.2 and 3.0
branches? Should we split out reggie, outrigger, JERI, etc into
their own repositories/deliverables? Should we have a set of
repositories that reflect our release engineering processes? i.e. a
development repo, QA repo, release repo, etc?
Simply “switching to git” and then having one big canonical git
repository that we use exactly the same way as we use svn doesn’t
seem to offer many advantages, really. If the argument is “but then
we could take Github pull requests”, well, we can already do that
with the git mirrors that are there already.
As far as “svn gets really messy for that kind of merge”, I’m not
convinced that’s a tool issue - the fundamental problem is that the
qa-refactor branch has diverged from the main branch for years
without a release or much attention from anyone but Peter, blowing
away the “develop on trunk” philosophy, and making “diffs” impossible
to evaluate. No tool is going to help that. We simply need to either
go through it revision by revision, or just accept it as “the way
forward”. We’ve decided to accept it.
For now, the current “jtsk/trunk” is an unknown factor as much as
“jtsk/skunk/qa-refactor-namespace/trunk”. I’d suggest renaming
“jtsk/trunk” to “jtsk/abandoned” or something, then rename
“jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release
from there. That’s the path of least bikeshedding.
Cheers,
Greg Trasuk
On Sep 22, 2015, at 9:40 AM, Patricia Shanahan <p...@acm.org>
wrote:
For moving to Git, see http://www.apache.org/dev/writable-git
Is the support provided sufficient? How do committers in general
feel about moving River to Git? If it is a good idea, should we do
it before Release 3.0? The alternative might be to rename the
current SVN branch and release from there.
On 9/22/2015 4:31 AM, Bryan Thompson wrote:
SVN gets really messy for this sort of thing. We wound not
bringing a project with a large delta back to the trunk because
of these issues and just did releases from branches after that.
What kind of support does Apache offer for switching to git?
That might be easier.
Thanks, Bryan
On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org>
wrote:
I think the next thing we need to do to make Release 3.0 a
reality is to merge it into the trunk.
If you agree, I would like opinions on the best way to go about
it. Ideally, we will preserve revision history for modules that
have moved from one directory/package to another.
