# Re: Trouble with git-svn when upstream svn URL changed 4 messages from 2006-12-08 to 2006-12-08. Participants: Eric Wong, Seth Falcon. Thread: https://gitlist.dev/t/43733 ## Seth Falcon, 2006-12-08 17:43 Subject: Trouble with git-svn when upstream svn URL changed Message-ID: URL: https://gitlist.dev/e/m21wnai8qe.fsf%40ziti.local ``` Hi, One of the repositories I have been tracking with git-svn was reorganized and the path that I have been tracking is now in a new location. I was hoping that the following would work: git clone orig new cd new git svn rebuild $NEW_URL I also tried git svn rebuild --remote $NEW_URL This have some output that looked reasonable (svn rev nums and git sha1's). But git svn fetch does nothing and I don't seem to have any of the new content. Am I using this incorrectly? I guess I can create a fresh git repos using git-svn init and then fetch all of my dev branches from the original repository. git version 1.4.4.1.g03c8-dirty (no changes to git-svn) Thanks, ``` ## Eric Wong, 2006-12-08 18:11 Subject: Re: Trouble with git-svn when upstream svn URL changed Message-ID: <20061208181109.GA10475@localdomain> URL: https://gitlist.dev/e/20061208181109.GA10475%40localdomain In-Reply-To: ``` Seth Falcon wrote: > Hi, > > One of the repositories I have been tracking with git-svn was > reorganized and the path that I have been tracking is now in a new > location. > > I was hoping that the following would work: > > git clone orig new > cd new > git svn rebuild $NEW_URL > > I also tried > > git svn rebuild --remote $NEW_URL > > This have some output that looked reasonable (svn rev nums and git > sha1's). But git svn fetch does nothing and I don't seem to have any > of the new content. Am I using this incorrectly? This is incorrect, rebuild is not designed to handle new urls. However, git/git-svn are very flexible beasts :) > I guess I can create a fresh git repos using git-svn init and then > fetch all of my dev branches from the original repository. You can look at "Advanced Example: Tracking a Reorganized Repository" in the manpage. Ignore the text about --follow-parent since you already have the old stuff fetched, and start following the instructions beginning with "# And now, we continue tracking the new revisions:" If that fails (I don't think it would); you can always link branches together using grafts (git-svn graft-branches tries to automate this; but it's imperfect). -- ``` ## Seth Falcon, 2006-12-08 18:34 Subject: Re: Trouble with git-svn when upstream svn URL changed Message-ID: URL: https://gitlist.dev/e/m2wt52fd8p.fsf%40ziti.local In-Reply-To: <20061208181109.GA10475@localdomain> ``` Eric Wong writes: > This is incorrect, rebuild is not designed to handle new urls. ok, I was lead astray by this part of the doc for rebuild: A Subversion URL may be optionally specified at the command-line if the directory/repository you're tracking has moved or changed protocols. > However, git/git-svn are very flexible beasts :) > >> I guess I can create a fresh git repos using git-svn init and then >> fetch all of my dev branches from the original repository. > > You can look at "Advanced Example: Tracking a Reorganized Repository" > in the manpage. Ignore the text about --follow-parent since you > already have the old stuff fetched, and start following the instructions > beginning with "# And now, we continue tracking the new revisions:" Oh, sorry I didn't find that example. This worked perfectly, thanks! One question: My fingers are in the habit of typing remotes/git-svn. Can I do: cd .git/svn rm -r git-svn mv git-newsvn git-svn Or is there a safer way to rename? Or are there other config-file ways to make this work -- to provide an alias? Thank you so much for the prompt reply. Nice to get going again and with the full history. ``` ## Eric Wong, 2006-12-08 19:13 Subject: Re: Trouble with git-svn when upstream svn URL changed Message-ID: <20061208191301.GA13944@localdomain> URL: https://gitlist.dev/e/20061208191301.GA13944%40localdomain In-Reply-To: ``` Seth Falcon wrote: > Eric Wong writes: > > This is incorrect, rebuild is not designed to handle new urls. > > ok, I was lead astray by this part of the doc for rebuild: > > A Subversion URL may be optionally specified at the > command-line if the directory/repository you're tracking has > moved or changed protocols. Hmm.. it seems that rebuild will work as intended iff you didn't clone (and therefore still have .git/svn/git-svn/.rev_db intact). Otherwise, it will rebuild the .rev_db file and ignore your specified URL. Perhaps running rebuild twice (specifying the URL on a second clone) after a clone would work. I honestly haven't used or looked at rebuild in a while. > > However, git/git-svn are very flexible beasts :) > > > >> I guess I can create a fresh git repos using git-svn init and then > >> fetch all of my dev branches from the original repository. > > > > You can look at "Advanced Example: Tracking a Reorganized Repository" > > in the manpage. Ignore the text about --follow-parent since you > > already have the old stuff fetched, and start following the instructions > > beginning with "# And now, we continue tracking the new revisions:" > > Oh, sorry I didn't find that example. This worked perfectly, thanks! > > One question: My fingers are in the habit of typing remotes/git-svn. > Can I do: > cd .git/svn > rm -r git-svn > mv git-newsvn git-svn > > Or is there a safer way to rename? Or are there other config-file > ways to make this work -- to provide an alias? You need to mv refs/remotes/git-newsvn refs/remotes/git-svn, too. Then it should be safe. -- ```