Re: Reconstructing git-svn metadata after a git clone

On 10 May 2010 22:43, Ævar Arnfjörð Bjarmason [off-list ref] wrote:

On Sat, May 8, 2010 at 18:20, Dmitrijs Ledkovs
[off-list ref] wrote:

quoted

On 8 May 2010 18:58, Ævar Arnfjörð Bjarmason [off-list ref] wrote:

quoted

So:

 * Am I doing something wrong? If so I can't see what it is.

No

quoted

 * 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 =)

If I can't resolve this I'll do something similar. Just provide a
tarball of .git/svn for each repo that is.

Always an option.

quoted

quoted

 * 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.

I still don't see why it can't work. Maybe I'm just hopelessly naïve
to git-svn internals, but:

  * Every commit message in the Git repo has info on the svn
    branch/svn commit.

  * The Git repo has a list of branches that map to SVN branches.

Your local one does. But not the cloned one.

  * If I supply the same `git svn init` options that made the repo,
    it should be able to bootstrap just using the above.

Yes, but it takes a while..... especially if the svn repo is huge.

Why isn't that the case? What info is in .git/svn that can't be
inferred from the above?

Is there a git versions mismatch between machine where the first
import was made and the machine where you are testing bootstrapping by
any chance?

on my machine I sometimes see "upgrading metadata" when I'm updating
some of my acient git-svn clones.

quoted

quoted

 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.

That's informative. But from having used Bazaar a bit my experience
with it was that I might as well be using Subversion.