You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Daniel Spiewak <dj...@gmail.com> on 2009/05/16 01:20:52 UTC
Suggestions on Environment Setup?
My committer creds finally came through! :-) Anyway, I would like to get
setup so I can commit to the SVN and push to the Git townhall, but this
seems to be a somewhat non-trivial process. Critically, I want to be able
to preserve all of the branches (both local and remote) and customizations
that I've built up as part of my GitHub fork. Any suggestions on the best
way to do this? Actually, this should probably be on a wiki page somewhere,
but until then...
Daniel
Re: Suggestions on Environment Setup?
Posted by Assaf Arkin <ar...@intalio.com>.
On Wed, May 20, 2009 at 6:08 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> :-) That's alright. I finally got things working myself. Step one
> (assuming an existing repository cloned from buildr/buildr):
>
> $ git remote add apache git://git.apache.org/buildr.git
> $ git fetch apache
> $ git branch trunk apache/trunk
>
> Step two:
>
> $ cd .git
> $ wget http://git.apache.org/authors.txt
> $ cd ..
> $ git config svn.authorsfile .git/authors.txt
>
> Step three:
>
> $ git checkout trunk
> $ git svn init --prefix=apache/ --username=djspiewak -s
> https://svn.apache.org/repos/asf/buildr
> $ git svn rebase
>
> At this point, you should have a fully-updated trunk/ branch in sync with
> the SVN repository. Now, the annoying part... For each local branch, we
> have to identify the exact branch-point; where that branch diverged from
> the
> SVN trunk/. Now, find the corresponding commit in the `trunk` branch and
> tag it as `branch-point`. Perform the following:
>
> $ git checkout *branch*
> $ git rebase branch-point
> # resolve any conflicts using mergetool
>
> If you do this for all your branches, you should get a working tree based
> on
> the new git clone. You can git svn dcommit from trunk/ and the results
> will
> be pushed into the SVN as expected. Running a git svn rebase in trunk/
> will
> bring it up to date with any new changes.
>
> The main disadvantage to this rebasing is that you will lose any merge
> history between your local branches. All of the commit data should still
> be
> there, but rebase will linearize it for each branch you rebase. In other
> words, if you started with four local branches with various cross-merging,
> you will end up with four local branches without any connectivity
> whatsoever. I think it's a small price to pay though for actually getting
> this working.
>
> Are we planning to re-sync the "townhall" based on the official Apache
> clone? I would vote "no" on this one, instead pointing Git-hungry people
> to
> the official source. Our personal clones can (and I believe, should)
> remain
> on GitHub, since it makes for a very nice way to collaborate. We should
> however try to get everything rebased against the same commit tree. :-)
> Also, for the sake of GitHub's pretty graphs, we should also build our
> repositories by using the "Fork" mechanism. My repository on GitHub is
> currently in sync with the above (except that `trunk` is a local branch and
> `master` contains some other stuff). If we decide on a central "fork
> point", I will recreate the GitHub repo based on that fork and then fold in
> my changes *again*.
+1 to all of these points.
Assaf
>
>
> Daniel
>
> On Wed, May 20, 2009 at 7:24 PM, Assaf Arkin <ar...@intalio.com> wrote:
>
> > On Fri, May 15, 2009 at 4:20 PM, Daniel Spiewak <dj...@gmail.com>
> > wrote:
> >
> > > My committer creds finally came through! :-) Anyway, I would like to
> > get
> > > setup so I can commit to the SVN and push to the Git townhall, but this
> > > seems to be a somewhat non-trivial process. Critically, I want to be
> > able
> > > to preserve all of the branches (both local and remote) and
> > customizations
> > > that I've built up as part of my GitHub fork. Any suggestions on the
> > best
> > > way to do this? Actually, this should probably be on a wiki page
> > > somewhere,
> > > but until then...
> >
> >
> > my git-svn is still broken, though I did progress into a different error
> > (and infinite loop on svn fetch) since upgrading to 1.6.3.1, so right now
> > I'm not the best person to ask :-)
> >
> >
> > >
> > >
> > > Daniel
> > >
> >
>
Re: Suggestions on Environment Setup?
Posted by Daniel Spiewak <dj...@gmail.com>.
:-) That's alright. I finally got things working myself. Step one
(assuming an existing repository cloned from buildr/buildr):
$ git remote add apache git://git.apache.org/buildr.git
$ git fetch apache
$ git branch trunk apache/trunk
Step two:
$ cd .git
$ wget http://git.apache.org/authors.txt
$ cd ..
$ git config svn.authorsfile .git/authors.txt
Step three:
$ git checkout trunk
$ git svn init --prefix=apache/ --username=djspiewak -s
https://svn.apache.org/repos/asf/buildr
$ git svn rebase
At this point, you should have a fully-updated trunk/ branch in sync with
the SVN repository. Now, the annoying part... For each local branch, we
have to identify the exact branch-point; where that branch diverged from the
SVN trunk/. Now, find the corresponding commit in the `trunk` branch and
tag it as `branch-point`. Perform the following:
$ git checkout *branch*
$ git rebase branch-point
# resolve any conflicts using mergetool
If you do this for all your branches, you should get a working tree based on
the new git clone. You can git svn dcommit from trunk/ and the results will
be pushed into the SVN as expected. Running a git svn rebase in trunk/ will
bring it up to date with any new changes.
The main disadvantage to this rebasing is that you will lose any merge
history between your local branches. All of the commit data should still be
there, but rebase will linearize it for each branch you rebase. In other
words, if you started with four local branches with various cross-merging,
you will end up with four local branches without any connectivity
whatsoever. I think it's a small price to pay though for actually getting
this working.
Are we planning to re-sync the "townhall" based on the official Apache
clone? I would vote "no" on this one, instead pointing Git-hungry people to
the official source. Our personal clones can (and I believe, should) remain
on GitHub, since it makes for a very nice way to collaborate. We should
however try to get everything rebased against the same commit tree. :-)
Also, for the sake of GitHub's pretty graphs, we should also build our
repositories by using the "Fork" mechanism. My repository on GitHub is
currently in sync with the above (except that `trunk` is a local branch and
`master` contains some other stuff). If we decide on a central "fork
point", I will recreate the GitHub repo based on that fork and then fold in
my changes *again*.
Daniel
On Wed, May 20, 2009 at 7:24 PM, Assaf Arkin <ar...@intalio.com> wrote:
> On Fri, May 15, 2009 at 4:20 PM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> > My committer creds finally came through! :-) Anyway, I would like to
> get
> > setup so I can commit to the SVN and push to the Git townhall, but this
> > seems to be a somewhat non-trivial process. Critically, I want to be
> able
> > to preserve all of the branches (both local and remote) and
> customizations
> > that I've built up as part of my GitHub fork. Any suggestions on the
> best
> > way to do this? Actually, this should probably be on a wiki page
> > somewhere,
> > but until then...
>
>
> my git-svn is still broken, though I did progress into a different error
> (and infinite loop on svn fetch) since upgrading to 1.6.3.1, so right now
> I'm not the best person to ask :-)
>
>
> >
> >
> > Daniel
> >
>
Re: Suggestions on Environment Setup?
Posted by Assaf Arkin <ar...@intalio.com>.
On Fri, May 15, 2009 at 4:20 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> My committer creds finally came through! :-) Anyway, I would like to get
> setup so I can commit to the SVN and push to the Git townhall, but this
> seems to be a somewhat non-trivial process. Critically, I want to be able
> to preserve all of the branches (both local and remote) and customizations
> that I've built up as part of my GitHub fork. Any suggestions on the best
> way to do this? Actually, this should probably be on a wiki page
> somewhere,
> but until then...
my git-svn is still broken, though I did progress into a different error
(and infinite loop on svn fetch) since upgrading to 1.6.3.1, so right now
I'm not the best person to ask :-)
>
>
> Daniel
>