On Tuesday 12 January 2010 21:52:24 Sean Phelan wrote: > Chris, > > Although I'm fluent in SVN, I know nothing about GIT, and it sounds like > any real technical debate on the 2 tools won't work unless someone can > lay them both out with a glossary.
And I have the reverse problem. However, thankfully there are plenty of people who have experience with both, so it is possible to find what you're looking for. This first page has a list of actions and the comamnds you would use for either Git or Svn, which looks like it fits what you need: http://git.or.cz/course/svn.html This page has a list of features Git and SVN have over each other: http://git.or.cz/gitwiki/GitSvnComparsion This author seems to have switched from SVN to Git and seems to be making a case for Git, but along the way he shows both sets of commands and I'm including it only because it's the first time I've seen the 'git stash' command used: http://markmcb.com/2008/10/18/3-reasons-to-switch-to-git-from-subversion/ > > You can think of a "superproject" as yet another Git repository that > > contains other Git repositories > > This is exactly what I often do with SVN - I have some projects with > nothing in them but a collection of externals definitions. Well yes, but I think SVN's externals are a bit more flexible in how they can be used than Git's superproject submodules. Git's 'superproject' sounds like it is ONLY meant to be used as a layer on top, whereas SVN externals CAN be used that way but don't have to be. [And this belief is based solely on the understanding I have from reading about these features.] > As for terms ... with git, you mentioned "clone", "wrapper", and "pull". > > With SVN, I'd be talking about "external", checkout, commit, status, and > update. > > That's why I think we have a bit of a language barrier comparing the > two. And I KNOW there is a concepts barrier, since GIT is definitely not > just the next subversion. Sure. Vocabulary takes time to understand -- for a new field I'm not familiar with it usually takes me about six months before I can fluently talk to someone whose been in that field for a while. Re-learning is usually shorter, but un-learning can be difficult. > Some groups are bridging the 2 together ... SVN for the master > repositories, and GIT for the working ones. Apparently, there are some > tools that do local conversions from git to svn and back. Yes I'm aware of some tools like git-cvs and git-svn that can do that, but as Sean mentioned during his talk there are some issues with their use, in that behind the scenes Git is silently doing a 'rebase' in order to write linear history when making an SVN or CVS commit, which taints the local Git repository in a way such that it should not be shared with others from that point. [I'd like to think that a git-svn commit could be done from a local Git branch so that the master branch doesn't get tainted that way, but perhaps that's optimistic.] SVN for the master and Git underneath sounds interesting, because the Git superproject methodology sounds like it creates a few workflow issues. > At some point, I'd like to see a case study of someone who switched from > SVN to GIT and how it was better ... or worse. I suspect you'll be able to find both kinds of situations. > I could have written that case study from CVS to SVN based on personal > experience. I'm sure there are some other sites with good writeups of > svn-vs-git. Not just features, but actual benefits. As you can see, there are. -- -- Chris -- Chris Knadle [email protected] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Feb 3 - Arduino Mar 3 - Sahana and 7 Years of MHVLUG Celebration Apr 7 - Nagios
