Moving from SVN to Git in 1,000 easy steps
codeascraft.etsy.com
Moving from SVN to Git in 1,000 easy steps
1–10 of 70 posts
Re: Moving from SVN to Git in 1,000 easy steps
#2It's really excellent to read a guide on this kind of thing that focuses on the difficult human factors rather than the easier technical ones.
Re: Moving from SVN to Git in 1,000 easy steps
#3Moral of the story: If you're on SVN right now, abandon it as soon as possible. Moving even a 2000 commit repo is no fun, especially when there are more developers involved.
Re: Moving from SVN to Git in 1,000 easy steps
#4Moral of the story: If you're on SVN right now, abandon it as soon as possible. Moving even a 2000 commit repo is no fun, especially when there are more developers involved.
I read it as Moral of the story: don't switch from SVN unless you have good reason OR small team with not a lot of commits.
Re: Moving from SVN to Git in 1,000 easy steps
#5Speaking as a long-term Subversion and Perforce user, I'm finding the switch to Git (forced on me by a job change) painful. My old work flow:
1. Commit my code to the central repo.
My new and "improved" Git workflow:
1. Commit my code to my local branch. 2. Push my local branch to the central repo.
As we're using Git as a centralised source control anyway, what is this extra work saving me over using a "traditional" centralised source control? In other words, what's the point in using a decentralised source control system in a centralised manner, and how many teams are truly using Git in a decentralised manner?
Re: Moving from SVN to Git in 1,000 easy steps
#6Speaking as a long-term Subversion and Perforce user, I'm finding the switch to Git (forced on me by a job change) painful. My old work flow: 1. Commit my code to the central repo. My new and "improved" Git workflow: 1. Commit my code to my local branch. 2. Push my local branch to the central repo. As we're using Git as a centralised source control anyway, what is this extra work saving me over using a "traditional"…
It's saving you because you can freely commit without ever running into a conflict suprisingly.
Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.
Re: Moving from SVN to Git in 1,000 easy steps
#7[deleted]
Re: Moving from SVN to Git in 1,000 easy steps
#8Moral of the story: If you're on SVN right now, abandon it as soon as possible. Moving even a 2000 commit repo is no fun, especially when there are more developers involved.
I read it as Moral of the story: don't switch from SVN unless you have good reason OR small team with not a lot of commits.
The moral of any story involving SVN is: "Switch from SVN".
Re: Moving from SVN to Git in 1,000 easy steps
#9Speaking as a long-term Subversion and Perforce user, I'm finding the switch to Git (forced on me by a job change) painful. My old work flow: 1. Commit my code to the central repo. My new and "improved" Git workflow: 1. Commit my code to my local branch. 2. Push my local branch to the central repo. As we're using Git as a centralised source control anyway, what is this extra work saving me over using a "traditional"…
It's saving you because you can freely commit without ever running into a conflict suprisingly. Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.
I could commit pretty freely using Subversion or Perforce to. As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo. Reading the original article, it seems his reason for switching to Git can be summed up in one word: Github.