3 ms·
I've developed a couple of Open Source stuff and I wanted to push them online. In my old company, they used SVN for almost everything (even Graphic designs, som
by neya 14y ago
I've developed a couple of Open Source stuff and I wanted to push them online. In my old company, they used SVN for almost everything (even Graphic designs, sometimes!) and hence I kind of knew SVN pretty well. I wanted to give GIT a fair trial, just to make sure I don't miss out something good, out of the personal bias in favor of SVN. And hence, I read some books, documentation and several other resources just to learn this GIT, simply because I saw it was a popular choice amongst many communities, including HN.
My thoughts in this entire learning process was along the lines of - "Why the hell are they doing it like this, instead of that? Why are they calling this, like that, instead of just calling it what it already is?"
In my experience trying to learn GIT, I was able to conclude that GIT introduces a LOT of terminologies, and concepts, making the path for beginners like me more and more difficult. Whether spending hours learning these concepts just to get your stuff synced properly depends on your scenario. But for me, SVN rules.
Also, there is another REALLY brilliant way by which SVN helps me. I use Tortoise SVN. I have a couple of external 1tb hard-drives to back-up my code. I like to take regular backups (obviously) because some of the code is in production and I just want to play it safe. Using SVN, on windows, I run an SVN server on my machine, and create respective repo's on my hard-drives and just update them and voila - I have all the code properly backed-up and versioned. You can also automate this (there are scripts to do them), but for me, I like to keep it synced manually. And also, you can keep your stuff backed-up to your Google drive by making a repository inside your drive folder. I can't imagine typing all these as commands in GIT.
- ekimekim 14y agoOnce again, it isn't fair to compare an SVN GUI to the git command line. Try some of the many git GUI wrappers and come back.
- neya 14y agoI've tried the official Github Windows GUI interface and still found it fairly confusing.
- Mordak 14y agoI guess the significant difference is that with git, all copies of a repository are full working repositories in and of themselves. So there is no difference between the repository on your git server and the copy you cloned onto your workstation (that's why it's 'clone' and not 'checkout'). This makes some things easier. If the 'server' dies, you can substitute any other copy of the repository for the original. So if github disappears I can still continue to hack away on my code like usual (commit, branch, merge, etc), and if I decide to publish on gitorious or something later, then I just push my local repository up and everything is there (full history, etc). This sort of obviates the need for 'backups', since your copy is already a backup, but making extra backups of any repository is as trivial as copying it (rsync) or cloning it to somewhere else (cd /backup; git clone /myrepo) - so I don't need to run a server or anything to make backups. As a thought experiment to illustrate the practical difference, consider why pull requests are so trivial to implement on github, and how would they work on the hypothetical svnhub?
- sanderjd 14y ago> In my experience trying to learn GIT, I was able to conclude that GIT introduces a LOT of terminologies, and concepts, making the path for beginners like me more and more difficult. So does Subversion, but you have already learned its terminology and concepts and are no longer a beginner.