views:

60

answers:

2

I'm new to git and I'm trying to understand if it can solve my problem.

A project has a public read-only svn repo. I want to make and track my own changes to its source over time. While still fetching changes from the svn repo. Of course I can do this easily with git-svn. I just never performing a dcommit.

The added issue is that I work from multiple locations. Thus I use a remote repo to sync files between these locations. This is also another thing I can do easily with git, using a remote git repo.

But put them together and I have:

  • fetch from remote svn
  • commit to local git
  • pull/push to remote git.

Is this a reasonable workflow with git? When, over time, my own changes/commits will be interlaced with updates from the svn repo. If so, how should I set it up.

Meaning, Should I have each working location have its local git fetch from the remote svn directly, in a fully decentralized fashion. Or should I go out of my way to have the single remote git repo do the svn fetch itself. To make it easier on the various local gits to coordinate the changes from svn, i.e. make them look like their just changes from the remote git repo.

I can run git-svn only on the remote git repo host if I need to.

A: 

Git can do this quite easily.

Try this:

git svn clone svn-url

That takes care of fetching from the remote svn. You can then use git as you like with branches etc and continue git svn pulling on master, merging changes into your development branch etc. I tend to use a separate repository though and do this:

git remote add svn /path/to/git/repo/cloned/from/svn

And pull from the svn clone into my development repository. It's just personal preference but it keeps my "import" repository clean and my development repository just thinks its the upstream code base. I could pull from other git repositories this way too; I'm never sure about doing so on top of a git-svn repository because I never personally commit back to svn... yet. You can then

git remote add server remote-repo
git push server {branch}

As per normal.

Ninefingers
A: 

If you can run git-svn on your remote server, I'd go for a setup like this:

  • use a special branch for tracking the upstream svn repository. Make the server hosting the git repository track the remove svn using git-svn in a known branch (f.e. upstream).
  • pull from that remote repository
  • use a separate branch for your changes (or multiple topic branches). Merge the the upstream branch changes to your topic branch(es). You can then always diff between your topic branch and the upstream branch and check the differences. If you don't publish the topic branch you can also use rebase, so you get your changes always as patches on top of the upstream changes.

If you can't run git-svn on the remote server I'd do it pretty similar, but having the remote server pulling the svn changes is much nicer as you don't need to worry about it.

bluebrother