CODEWITHSUNDEEP
gitsvn
kroiz
kroiz

Reputation: 1772

Working remotely and disconnected from SVN

Imagine two physical places in this world:

  1. With the master svn repository - but no internet.
  2. A copy of the master repository files; but not currently in any VCS.

Now as programmer my job is to work in these two places (on the same feature), mainly in the second site and once or twice a week in the first site.

To sync files between these two places, I burn the changed files to a CD, go to the other location and carefully merge each file. Also, not sure if it is relevant, but there are other programmers working on that project with me. Some have site 1 as their main office, and some have site 2 as their main office.

I cannot change the fact the the main repository in site 1 is svn, but this seems like a distributed environment, so how can I use git to make moving and merging files easier between these sites?

Upvotes: 0

Views: 309

Answers (3)

David W.
David W.

Reputation: 107090

Subversion mainly works with the repository. Subversion was designed to work without a repository connection for the short term, but in the end, you need to repository. Otherwise, you cannot commit changes. This might not be bad for a day or two, but is a major problem if you're talking about weeks or months.

One solution is to move to a distributed repository model. Using git-svn will allow you to checkout from the Subversion repository, and push your changes back to that repository. Your merging issues (no syncing for weeks between your work and the remote), but at lest you'll be able to use version control on your work.

Is it possible to get that site With the master svn repository - but no internet to move to Git? What most people don't understand with Git is that you don't necessarily have one central repository, but you can have multiple repositories you're pushing and pulling changes between. For example, you can push a change to a Git repository using email. This way, your code changes could be delivered when your still off site. Or, you can push your code changes to a coworker's Git repository, and that coworker could push your changes to the master repository.

Git is a bit more complex than Subversion (after all, you have at least one extra repository you have to work with when using Git), but in this case, using a distributed version control system may make everyone's life much easier.

Upvotes: 1

gammay
gammay

Reputation: 6215

You can consider doing this with svn itself.

  1. Create a new SVN repo in site 2 with a dump taken from site 1.
  2. Commit changes to site 2 repo
  3. Take dump (export, not checkout) from repo 2 on CD/portable HDD to site 1
  4. At site 1, checkout
  5. Merge files from repo2 to repo1 (you can do most of it automated by using a good tool)
  6. Checkin to site 1
  7. Take a new dump from site 1 and create a new repo at site 2 (no need to merge back to site 1).

Even if you use git, manual intervention will be needed if there are conflicts. If you use a good compare-merge tool, merge is not that time consuming. You can write a script to automate all the steps.

Upvotes: 1

kirelagin
kirelagin

Reputation: 13626

You can use git on your machine and then sync it with the SVN repo with git-svn. I'm not sure whether this will make your workflow any easier… I mean, if you like git, you'll be able to use git for your development most of the time, but syncing back to SVN will be a pain anyway.

Upvotes: 0

Related Questions