7

I have read these related questions:

...and I understand why git is useful. What I don't understand is why tools like git-svn that allow git to integrate with svn are useful.

When, for example, a team is working with svn, or any other centralised SCM, why would a member of the team opt to use git-svn? Are there any practical advantages for a developer that has to synchronize with a centralized repository?

Community
  • 1
Wes
  • 824
  • 1
  • 7
  • 16
  • 1
    For the downvoters. What is wrong with the question too localised? Not enough info already covered? same for the close voters. – Wes Nov 26 '12 at 18:21
  • 1
    I downvoted because I believe your question is already adequately answered elsewhere, even in the links you posted, and your question asks for a "list of things." If you can make your question more focused and specific, I'll lift my downvote. – Robert Harvey Nov 26 '12 at 18:25
  • @RobertHarvey: `The disconnected nature of Git allows you to take the code base with you, work on it during a plane trip, and synchronize your changes when you get back.` And what is preventing you from doing that with any other VCS? I do offline work on SVN-based projects all the time, and I really have no idea what you think the one has to do with the other. – Mason Wheeler Nov 26 '12 at 18:30
  • 1
    @MasonWheeler you can continue to commit with GIT is that point. Its a well established point and I think worthy of an answer. Not specifically useful to me except maybe when office internet dies. – Wes Nov 26 '12 at 18:33
  • 1
    @MasonWheeler True. It's mostly a matter of personal preference, first time I went for an equivalent hg based schema was only as an excuse to learn a bit more about hg, there was no practical need svn couldn't cover. I suspect the same is true for git as well. – yannis Nov 26 '12 at 19:54
  • @MasonWheeler: I do recall commenting on this question, but my comment seems to have disappeared. – Robert Harvey Nov 26 '12 at 21:38
  • @RobertHarvey you commented above still there – Wes Nov 26 '12 at 22:00
  • OK, that's a little weird. The only comment of mine that I see is the one explaining my downvote. – Robert Harvey Nov 26 '12 at 22:17
  • oh yeah your right the first one was the google one. – Wes Nov 26 '12 at 22:19
  • 1
    **voted to reopen**: changes made in [revision 3](http://programmers.stackexchange.com/posts/177229/revisions) resolved concerns I had with original question wording – gnat Nov 27 '12 at 08:08
  • **didn't vote to reopen**: Question is already adequately answered. – Robert Harvey Nov 27 '12 at 16:21

6 Answers6

18

Forcing a company to move from one VCS to another is a big decision to make. Git is a big learning curve for people who have only used SVN, no matter what people tell you. If you have a team of 30 of those people, it doesn't matter how good an idea a switch to Git is, it's a big decision.

But, if you prefer a DVCS (I do, just for the ability to do fast, regular commits, without pushing them to the build server), there should be nothing stopping you, personally, from using it, without causing major disruption to everyone else. After all, DVCS is just the ability to clone a central database and then clone it again and again.

And that's what Git-Svn (or even Git-tf) does for you. No one else even needs to know that you're using it.

Slowly, you can convert people over to the dark side and, if there is ever enough of a pro-Git movement to make it worth everyone's while, you can shift the central repository over to Git.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • 3
    just an interesting comment I got caught out today by committing a .gitignore – Wes Nov 26 '12 at 18:34
  • @Wes: Ha. I put a .gitignore in our central repo weeks ago. No one has questioned it. Ok, so they know you're using it, but it doesn't affect them at all, so it's no different from their not knowing. – pdr Nov 26 '12 at 18:36
  • 1
    i assume if I could convince 1 other team member to use it all the usual benefits would apply. or most as the user would have to dcommit their own work. better than sharing .patch files – Wes Nov 26 '12 at 20:12
  • You might want to add that git-svn has scripts to convert an entire svn archive to a git one. I used one of these last week to switch our team to git and it worked great. – GlenPeterson Nov 26 '12 at 21:10
  • @GlenPeterson: Which is a good thing, but not really related to the question. – pdr Nov 26 '12 at 21:14
  • Where a software house that has an entire echo-system built around SVN, and is not going to switch to GIT, with the requisite rewrite of that echo system- git-svn allows the benefits of GIT for the teams. I recently had that as a remote contractor with no direct access to the SVN repo, we used git-svn to manage our workflow. – mattnz Nov 27 '12 at 04:30
9

I use git-svn because I use my own local (and PRIVATE) branches for organizing my workflow and for experimenting. With centralized I can't create a branch unless it is on the server where everyone else has access. I suppose one could set up special permissions/groups on the server such that when a branch is created only I have access but TBH that seems like more work than necessary.

And we are moving to git as our central SCM, it's just a few months away but it allows developers to learn git without having to change the entire infrastructure.

Heath Lilley
  • 1,290
  • 9
  • 12
  • 3
    Indeed, one of the most important features of DVCS is that it separates the notion of *recording* a version and *publishing* a version. And if you can see why that's useful, then the idea of using two different systems to record published vs. unpublished history kind of falls out naturally. After all, they are two different repositories, why would they need to use the same storage format? – Jörg W Mittag Nov 26 '12 at 19:42
6

Using Git combined with SVN can be useful if your develop under strict check-in rules. For example checking into the central repository may require peer reviews, unit test cases, design docs, and several paper forms.

Although these rules are good, they makes check-ins to the central server a burden. I've found developers tend to wait and do a giant check-in to consolidate the paper work.

With GIT you can check-in locally so you have many little save points as you develop. It's just your local disk so you don't need to do any peer-review, paper work, or unit test documents.

You gain a much richer set of save points as you develop. And save points are the entire point of using source control (over old fashioned backups).

mike30
  • 2,788
  • 2
  • 16
  • 19
  • It's quite easy to setup svn locally and follow the exact same workflow you're describing. – yannis Nov 26 '12 at 19:56
  • 1
    @YannisRizos A local repo you can commit, branch, and merge within, while still being able to commit to the central server? I've never heard of SVN being able to do that without hackery... – Izkata Nov 26 '12 at 20:50
  • @Izkata SVK is not that hackery, but getting it to play nicely with an existing SVN repo might be a bit. Since 1.5 svn supports write through proxy setups, but I guess that's also a bit hackery compared to svn-git (see:http://blogs.atlassian.com/2008/11/subversion_replication_at_atla/) - In any case, I've moved on to hg and I'm very happy about it ;) – yannis Nov 26 '12 at 21:25
3

One other point to make is that it's less likely that a developer on a project is going to "go rogue" and use git while the rest of the team uses SVN, but it is likely that an entirely different group of developers wants to use and develop a project that uses SVN and this group prefers git.

For example, our group uses an open-source chemistry software that is hosted online with SVN. But we have changes we make internally that will not leave our group and we all know git. So rather than force everybody to learn both, we just let an educated one or two figure out git-svn and clone the project into an internal repository. And then our development processes continue without issue.

Even if we were not to make changes, some people are not programmers and can't (or really, won't) learn how to use both git and SVN. So we provide an intermediate step for those users, all they need to know is how to clone with git.

tpg2114
  • 131
  • 3
3

My reasoning are somewhat less sophisticated than the other guys - but it's mostly combining the best of both worlds (my own local branches, stash, detached from the main repo).

As for the advantage of keeping SVN - single revision number for everyone - starting from support, developers, managers... all the way up to the managing director. And yes - I'm aware of git describe, but unfortunately: I need more than that to convince ppl.

YS.
  • 131
  • 3
2

There are many good answers already with some key reasons like

  • Offline/Private/Experimental commits
  • Exchange within small subgroups outside the main svn tree

But in my opinion there is another major reason to use git-svn for svn projects: Quickly accessible history. With svn you need a net connection for anything more than a simple svn diff. Depending on your location relative to the repository server and the server's load examining the history to find reasons for a potential bug or such can be quite slow. With git it only depends on the speed of your local disk. and then, thanks to git's compression, many history-related operations are quite fast.

gnat
  • 21,442
  • 29
  • 112
  • 288
johannes
  • 3,601
  • 2
  • 26
  • 32