Re: Reconstructing git-svn metadata after a git clone

[Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>]

On 8 May 2010 18:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> So:
>
>  * Am I doing something wrong? If so I can't see what it is.
>

No

>  * Is there something that works for the general case, i.e. you only
>   have to know the original `git svn init` options. If there is I'd
>   like to document that & submit a patch.
>

In my repo I have a branch with no anestors which has a config file,
setup.sh & fetch.sh

I instruct to clone repo, checkout "utils" branch, run setup.sh (it
overrides .git/config with config file committed to utils branch and
after it copied config it runs git svn init URL), fetch.sh just runs
git svn fetch =)

I have to do this because I have two svn remotes and both are not
standard layout. The only way for me to represet "same init options"
is by editing .git/config cause it's impossible for me to supply
git-init options on the command line =)

>  * Depending on the above; can git-svn itself be friendlier here?
>   Maybe by having a `git svn bootstrap` command. E.g.:
>

It would be nice to have the git init info propogate with the git
clone. But this won't work. You are cloning *all* branches and
providing a git mirror, where as I want to to git init just my svn
branch or a subset of them. To achieve that I will clone just the
branches I need modify my .git/config and get the result I want.

So imho git-svn is ok here.

>  git clone git://$some_url
>  # Does all the work of setting up metadata/refs
>  git svn bootstrap --stdlayout $remote_svn_url


If you are committing to svn regularly you are better of with bzr-svn
in my opinion. Because launchpad can run automatic imports for you
(webkit is already running btw) and the whole bootstrapping thing is
done the way you are expecting it.

#create repository to store revisions efficiently
$ bzr init-repo .

#on the first ever run it will rebuild meta-data
#subsequent runs just fetch missing revisions
$ bzr branch svn://path.to.any.branch

And you can commit from that =) and bzr can operate on your svn
checkouts. And every single clone done by bzr-svn is identical (unlike
git where everyone has to follow the same git-svn mirror to get same
revision-ids).

You have two options when commiting with bzr-svn. Regular bzr ci will
store bzr merge information in revision properties on svn server or
you can use bzr dpush which is like git svn dcommit.

IMHO bzr-svn is the best when you need to commit back to svn and
painlessly commit parts of the feature branch and merge other bits
later.