git-svn clone on a central server

git-svn clone on a central server

[Bruno Harbulot]

Hello,

I'm trying to follow example 3 of the git-svn manpage, since I'd like to 
keep a "central" clone of a subversion repository (and rebase it 
regularly) on a server and work on local git repositories based on that 
server's git repository.
However, I can't get this example to work:

# Do the initial import on a server
    ssh server "cd /pub && git-svn clone http://svn.foo.org/project
# Clone locally - make sure the refs/remotes/ space matches the server
    mkdir project
    cd project
    git-init
    git remote add origin server:/pub/project
    git config --add remote.origin.fetch=+refs/remotes/*:refs/remotes/*
    git fetch
# Initialize git-svn locally
    git-svn init http://svn.foo.org/project
# Pull the latest changes from Subversion
    git-svn rebase

('--add' doesn't work in git config, but I guess that's not required).

I get this error:

$ git-svn rebase
fatal: ambiguous argument 'HEAD': unknown revision or path not in the 
working tree.
Use '--' to separate paths from revisions
log --no-color HEAD: command returned error: 128


I've then tried:

$ git checkout origin/master
warning: You appear to be on a branch yet to be born.
[...]
$ git branch master
$ git checkout master
$ git-svn rebase

However, this produces this error:
'Unable to determine upstream SVN information from working tree history'


Any idea how to solve this?

Best wishes,


Bruno.

Re: git-svn clone on a central server

[Peter Harris]

On Sat, Mar 15, 2008 at 3:38 PM, Bruno Harbulot
<Bruno.Harbulot@manchester.ac.uk> wrote:
>  I'm trying to follow example 3 of the git-svn manpage, since I'd like to
>  keep a "central" clone of a subversion repository (and rebase it
>  regularly) on a server and work on local git repositories based on that
>  server's git repository.
...
>  I get this error:
>
>  $ git-svn rebase
>  fatal: ambiguous argument 'HEAD': unknown revision or path not in the
>  working tree.

You have to git reset --hard <branch> to create 'master' based on a
particular svn branch, or git-svn won't know what to rebase.

I sent a documentation patch to this list back in February, but it
appears to have been dropped. I should probably re-send it...

http://article.gmane.org/gmane.comp.version-control.git/72954

Peter Harris

Re: git-svn clone on a central server

[Bruno Harbulot]

Peter Harris wrote:
> On Sat, Mar 15, 2008 at 3:38 PM, Bruno Harbulot
> <Bruno.Harbulot@manchester.ac.uk> wrote:
>>  I'm trying to follow example 3 of the git-svn manpage, since I'd like to
>>  keep a "central" clone of a subversion repository (and rebase it
>>  regularly) on a server and work on local git repositories based on that
>>  server's git repository.
> ...
>>  I get this error:
>>
>>  $ git-svn rebase
>>  fatal: ambiguous argument 'HEAD': unknown revision or path not in the
>>  working tree.
> 
> You have to git reset --hard <branch> to create 'master' based on a
> particular svn branch, or git-svn won't know what to rebase.
> 
> I sent a documentation patch to this list back in February, but it
> appears to have been dropped. I should probably re-send it...
> 
> http://article.gmane.org/gmane.comp.version-control.git/72954

Thank you. This works. 'git reset --hard' was the key.

I've also managed to get it to work without '-s' (for just a 
sub-directory of the trunk) this way:
   ssh server "cd /pub && git svn clone -s 
http://svn.foo.org/project/trunk/subproject"
   mkdir subproject
   cd subproject
   git init
   git remote add origin server:/pub/subproject
   git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
   git fetch
   git svn init http://svn.foo.org/project/trunk/subproject
# The following line creates a master branch
   git reset --hard origin/master
   git svn rebase


The way I'm planning to use this is to create a "central" bare 
repository on the server (by moving the '.git' directory and setting 
bare=true in the config file) that I would like to keep in sync with the 
original SVN repository (and also push by own branches).
I'd like then to pull these changes to my working copies of that central 
repository. I'm not quite sure how to update this central bare git 
repository (and then its clones) with the changes in the SVN repository 
upstream. (By the way, I'm not planning to 'dcommit' anything directly, 
just reading from this SVN.) Are there any recommendation on how to 
achieve this?


Best wishes,


Bruno.

Re: git-svn clone on a central server

[Peter Harris]

On Sun, Mar 16, 2008 Bruno Harbulot wrote:
>  The way I'm planning to use this is to create a "central" bare
>  repository on the server (by moving the '.git' directory and setting
>  bare=true in the config file) that I would like to keep in sync with the
>  original SVN repository (and also push by own branches).
>  I'd like then to pull these changes to my working copies of that central
>  repository. I'm not quite sure how to update this central bare git
>  repository (and then its clones) with the changes in the SVN repository
>  upstream. (By the way, I'm not planning to 'dcommit' anything directly,
>  just reading from this SVN.) Are there any recommendation on how to
>  achieve this?

I run "git svn fetch" hourly (and "git gc" daily) from cron on my
'server'. My working copies, I just "git pull" when I want an update
as usual.

I also occasionally "git svn (fetch|rebase|dcommit)" in my working
copies. Just remember to blow away .git/svn after each "git
(fetch|pull)" so that git-svn knows to rebuild the local index. Also,
you just have to wait for the central 'server' to run another update
before your next "git (fetch|pull)", or it will rewind the state of
your svn branches.

(Also note that state can get out of sync if an svn log message or
author changes between the working copy's "git svn
(fetch|rebase|dcommit)" and when the server's cron job triggers -
basically never, unless you happen to have coworkers who like to
ammend their svn log messages shortly after making a commit)

I don't push branches to my 'svn fetch' repo (I use a separate repo
for that), but I don't see why it would cause a problem.

I'm sure there are other ways to do this.

Peter Harris