2

We have been using SVN for several years.

Recently, we switched over to git, since some members of the organization pointed out that if our SVN server dies our team is toast.

So far, we've got something worked out with the git workflow, however some team members really do not like this git process. They want to simply right-click on a file and then hit SVN Commit (we're using tortoiseSVN) without having to worry about all this pushing and pulling.

I've been asked to provide SVN support for our repository while keeping the git repo (hosted on github) updated. The workflow I'm imagining is that we'll all just do the normal SVN things as before, and then once in awhile I'll just do a push to github to backup our files.

What are some options for using git purely for backup purposes (one person would manage the git repo), while everyone uses the SVN repo?

I've read about git-svn, but it seems like a completely different tool. Perhaps someone can clarify this? If I checked out a svn repo using git-svn, would I be able to operate on it using tortoiseSVN? Or can everyone else use a regular SVN checkout, while I maintain a git-svn checkout?

6
  • why didn't you ask at Stack Overflow? meta.stackexchange.com/a/129632/165773
    – gnat
    Commented Mar 20, 2014 at 16:42
  • As far as I know, Github supports SVN. github.com/blog/626-announcing-svn-support
    – Knerd
    Commented Mar 20, 2014 at 16:46
  • 1
    @gnat there is no actual programming question, which seems to be the main reason why a lot of questions get closed.
    – MxLDevs
    Commented Mar 20, 2014 at 16:54
  • @Knerd oh hmm I never knew about that. I'll see if we can simply use github as our SVN repo!
    – MxLDevs
    Commented Mar 20, 2014 at 16:55
  • 1
    @gnat: this is a question where it is not clear if its more a technical or more an organizational problem. So I think its pretty ok to ask here.
    – Doc Brown
    Commented Mar 20, 2014 at 16:55

3 Answers 3

5

If you want just backups, I would recommend not to use git at all - that makes things unneccessarily complicated. Instead, backup your SVN server daily.

Of course, if you don't just want backups, but also mobile access to the repo, you could choose an svn hoster. Maybe this site will help you to pick one.

5
  • 2
    Git has other nice things, at the beginning, I hated git, now I love git and hate svn ;)
    – Knerd
    Commented Mar 20, 2014 at 17:06
  • 1
    @Knerd: the OP has clearly stated that they tried Git, but the team is convinced that the SVN workflow suites their needs better. So honestly, comments like "Git is better" won't help them much.
    – Doc Brown
    Commented Mar 20, 2014 at 17:11
  • I didn't wanted to say git is better. We had huge problems in changing to git from svn. Nearly everybody had problems with it. But before I left the company, git was better integrated than svn. Mostly the part with git-deploy was a reason why we changed at this point. One thing that git makes way easier are e.g. branching and merging.
    – Knerd
    Commented Mar 20, 2014 at 17:44
  • 2
    @Knerd Git does have nice things, but most of them (if any) are not useful to us. We just need version control and a way to share changes, and none of us really branch or merge due to the nature of our projects. For the most part, some members don't think the benefits that git can potentially give outweighs the ease-of-use that SVN provides.
    – MxLDevs
    Commented Mar 20, 2014 at 17:55
  • 2
    @DocBrown Thanks for the list. I'll probably stick with github as the SVN hoster since we can all choose which tools we want to use. I can continue to familiarize myself with git, the others can go with SVN, and the same repository is always up to date. Server backups are important, but mobile access is a good addition. People have always complained about having to connect through our slow VPN just to access our code.
    – MxLDevs
    Commented Mar 20, 2014 at 17:58
2

My advice is to get people skills up to date. I would push back against the assignment and say that adopting old work habits and patterns that don't match newer technology and processes is a bad decision for the future of the company and also for the future skills of the employees.

Technology is a constantly and continually evolving and changing. When new tools and practices become available, a large challenge is to get people to use the new tools in new ways. This can mean changing long-held beliefs and practices which is hard.

That also makes the challenge of hacing folks change a little easier. Explain that git, as a DVCS is a new way of working that is quickly supplanting older technology VCSs. Doing things the 'git' way is likely what they will be doing in a lot of their future jobs. If they 'do git the svn way' they are likely going to find their next job hard to do.

The move from svn to git is a particularly difficult one. It's difficult for many reasons including the fact that the same word means quite different (or even opposite) things.

Good git gui tools such as gitx(osx) or gitg(linux) can also help a lot.

You may also find this Q&A on workflow useful:
https://stackoverflow.com/questions/3329943/git-branch-fork-fetch-merge-rebase-and-clone-what-are-the-differences/9204499#9204499

0

Most git clients I am aware of can do push on commit for the SVN-style workflow so you can keep git for the modern guys and let the dinosaurs keep their SVN-style workflow without rolling back to SVN.

Having made the same transition myself I would try and fight the dinosaurs as one day git will dwan on them and all will be much better.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.