Re: Reconstructing git-svn metadata after a git clone

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10 May 2010 22:43, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote:
> On Sat, May 8, 2010 at 18:20, Dmitrijs Ledkovs
> <dmitrij.ledkov@xxxxxxxxxx> wrote:
>> On 8 May 2010 18:58, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.

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

>>>  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.
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]