Re: Reconstructing git-svn metadata after a git clone
- From
Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>
- Date
- May 11, 2010, 04:27 UTC
- Message-ID
- <AANLkTinMZvBUPPmChwrA1dHr47HXpFldnKH9GO60oIkU@mail.gmail.com>
- In-Reply-To
- <AANLkTin_hVhyrhjwoM_on_sd1RIZrk6YIFVsYXKm5UKg@mail.gmail.com>
On 10 May 2010 22:43, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 31 quoted lines
> On Sat, May 8, 2010 at 18:20, Dmitrijs Ledkovs > <dmitrij.ledkov@ubuntu.com> wrote: >> 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 =) > > 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.
Show 20 quoted lines
>>> * 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.
Show 32 quoted lines
>>> 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. >