What's your favorite Version Control System (VCS), and why?
Recently, a couple of other experts (I won't say who they I'll leave it up to then if they wish to 'fess up ) and I have been discussing which is our favourite/preferred VCS. I am an ex SubVersion user who finally saw the light and migrated myself (and my team where I work) over to Git and I have never looked back! I still on the odd occasion have to use SVN (we only migrated trunk and on the odd occasion we have to look at old branch code) and it makes me cringe!
Whilst I won't say this migration was a walk in the park it was also not that painful. Git comes with a tool that allows you to clone an SVN repo and it's pretty simple and quick. The most painful part was deciding to break our massive SVN repo into smaller Git repos; one for each project rather than all projects in one repo. This; however, was an internal design decision (it wasn't necessary just for the migration) and even if we'd not moved to Git we'd have eventually had to restructure our repo.
The nice thing about moving to lots of smaller repos are (a) I no longer have to have a mass of code on my laptop that I don't look after and (b) all our code is now fully de-coupled (we can no longer rely on things living in a specific place like we could in one monolithic repo), which means things are more robust -- although there was pain in getting to this point but it was worth the hassle.
I've never looked back since moving to Git. The workflow I get from using it is far superior (in my view) and flexible than that of SVN. Further, Git is just far simpler to use, more powerful (in terms of how cheap it is to branch and merge -- meaning I can experiment without the pain and fear of having to merge my changes (unlike with SVN).
Of course, there are also good arguments (this is where you come in!) for using a centralised VCS -- or, at least, this is what die-hard SVN/CVS/Other users firmly believe :)
So, I just wondered (and this is just for fun, so please no flaming wars!), which is your favourite VCS? Do you even use one? If not how to do manage version control? I'd especially be interested in hearing from anyone who is (forced into?) using Visual Source Safe; possibly the worse VCS ever -- I especially love the way it silently corrupts its contents, especially if you are pro using it :)
I look forward to your views... and I promise I won't let my own personal views cloud my decision when it comes to closing down and awarding points. What I'm after is some interesting and constructive discussion.
Thanks in advance for taking part :)
Whilst I won't say this migration was a walk in the park it was also not that painful. Git comes with a tool that allows you to clone an SVN repo and it's pretty simple and quick. The most painful part was deciding to break our massive SVN repo into smaller Git repos; one for each project rather than all projects in one repo. This; however, was an internal design decision (it wasn't necessary just for the migration) and even if we'd not moved to Git we'd have eventually had to restructure our repo.
The nice thing about moving to lots of smaller repos are (a) I no longer have to have a mass of code on my laptop that I don't look after and (b) all our code is now fully de-coupled (we can no longer rely on things living in a specific place like we could in one monolithic repo), which means things are more robust -- although there was pain in getting to this point but it was worth the hassle.
I've never looked back since moving to Git. The workflow I get from using it is far superior (in my view) and flexible than that of SVN. Further, Git is just far simpler to use, more powerful (in terms of how cheap it is to branch and merge -- meaning I can experiment without the pain and fear of having to merge my changes (unlike with SVN).
Of course, there are also good arguments (this is where you come in!) for using a centralised VCS -- or, at least, this is what die-hard SVN/CVS/Other users firmly believe :)
So, I just wondered (and this is just for fun, so please no flaming wars!), which is your favourite VCS? Do you even use one? If not how to do manage version control? I'd especially be interested in hearing from anyone who is (forced into?) using Visual Source Safe; possibly the worse VCS ever -- I especially love the way it silently corrupts its contents, especially if you are pro using it :)
I look forward to your views... and I promise I won't let my own personal views cloud my decision when it comes to closing down and awarding points. What I'm after is some interesting and constructive discussion.
Thanks in advance for taking part :)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>My guess that majority of programmers do not have a formal education in
>>Computer Science (university level). Because of that they often do not have
>>a big picture of the project infrastructure (the reasons why the things are
>>done this and that way, using the tools,...), and they do not see the
>>alternatives. They are just happy with what they have.
It gets worse - since I often get in contact with students from that field (Software Engineering, CS - evilrix and Infinity know where I meet them ;o) I felt tempted to ask which RCS they were told to use. Much to my dismay the answers basically boiled down to "Wuz dat?"
>>Computer Science (university level). Because of that they often do not have
>>a big picture of the project infrastructure (the reasons why the things are
>>done this and that way, using the tools,...), and they do not see the
>>alternatives. They are just happy with what they have.
It gets worse - since I often get in contact with students from that field (Software Engineering, CS - evilrix and Infinity know where I meet them ;o) I felt tempted to ask which RCS they were told to use. Much to my dismay the answers basically boiled down to "Wuz dat?"
>> It gets worse - since I often get in contact with students from that field
>> (Software Engineering, CS - evilrix and Infinity know where I meet them ;o)
>> I felt tempted to ask which RCS they were told to use. Much to my dismay
>> the answers basically boiled down to "Wuz dat?"
I know that situation very well. I was teaching at CS department for eight years (until 1997). I could observe the tendency of more and more "dumb" students. I do not like to say that, but it is true. There are definitely reasons for the situation. Briefly, more students are allowed to study, underpayed teachers often go to industry for better salaries, chidren now can have a lot of things and they are not "trained" to cope with difficult situations, to solve problems. They are not trained to focus on a problem, they easily give up. They prefer to consume and to play before to create and to look for themselves. But it is for another thread...
Frankly, I did not learned about VCS's at the school either (graduated in 1988). It was behind the iron curtain, personal computers were just few there. Also the style of programming and of organizing the team were different. Almost no Internet-like things, etc.
I suggest to return to the theme of the favourite Version Control Systems and why... :)
>> (Software Engineering, CS - evilrix and Infinity know where I meet them ;o)
>> I felt tempted to ask which RCS they were told to use. Much to my dismay
>> the answers basically boiled down to "Wuz dat?"
I know that situation very well. I was teaching at CS department for eight years (until 1997). I could observe the tendency of more and more "dumb" students. I do not like to say that, but it is true. There are definitely reasons for the situation. Briefly, more students are allowed to study, underpayed teachers often go to industry for better salaries, chidren now can have a lot of things and they are not "trained" to cope with difficult situations, to solve problems. They are not trained to focus on a problem, they easily give up. They prefer to consume and to play before to create and to look for themselves. But it is for another thread...
Frankly, I did not learned about VCS's at the school either (graduated in 1988). It was behind the iron curtain, personal computers were just few there. Also the style of programming and of organizing the team were different. Almost no Internet-like things, etc.
I suggest to return to the theme of the favourite Version Control Systems and why... :)
ASKER
>> I don't think that git imposes a workflow
That's not actually what I said. If you read my comment again you'll see I was implying that Git is flexible and, thus, allows me to adopt a workflow that suits me; unlike SVN.
Yes, branching in Git is cheap. It creates one 20 byte file; job done. Merging even thousands of lines of code is as cheap as updating that 20 byte file, if you branch has not diverged from its parent (ie, as long as it has a direct root back to the tip of the parent). Even if you branches have diverged it is rare for Git to take longer than a second to perform a full merge.
Git doesn't impose branching any more or any less that SVN but it makes it a damn sight simpler.
That's not actually what I said. If you read my comment again you'll see I was implying that Git is flexible and, thus, allows me to adopt a workflow that suits me; unlike SVN.
Yes, branching in Git is cheap. It creates one 20 byte file; job done. Merging even thousands of lines of code is as cheap as updating that 20 byte file, if you branch has not diverged from its parent (ie, as long as it has a direct root back to the tip of the parent). Even if you branches have diverged it is rare for Git to take longer than a second to perform a full merge.
Git doesn't impose branching any more or any less that SVN but it makes it a damn sight simpler.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I've used many VCS's, including CVS and SVN. Mostly use GIT now.
GIT can be confusing and complex. Possibly this is a documentation issue, although there are a number of tutorials and articles about it. Some areas, like sub-projects, are less than clear.
GIT can be confusing and complex. Possibly this is a documentation issue, although there are a number of tutorials and articles about it. Some areas, like sub-projects, are less than clear.
You may want to know that there is a book related to Git. It is named "Pro Git", by Scott Chacon under Creative Commons License -- http://progit.org/book/ I have just started to read it, no opinion yet.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I would like to expand this very interestion question in another direction. Please, have a look at "What is your experience with the transition to the chosen Version Control System?" http:Q_27327248.html. It should be namely about expectations before and after, about your experience and abou the experience of your co-workers.
ASKER
>> So, although I do intend to play with GIT, I have seen no evidence so far that it will be the major positive change that it's advertized to be
Before I started using Git I felt exactly the same way; then I actually tried using it. Initially I was like, wooah, this is a little complex. Once I got past that stage I realised just how powerful and flexible Git is and how it makes SVN look and feel like a dinosaur. I could never go back to using SVN now. Even if I do have to work with an SVN repo I do so via Git.
The thing is that Git has soooo many powerful features that, until you've actually worked with it for a while and learnt them, you just don't realise what you've got your hands on. It's easy to dismiss Git as just another VCS but it is so much more than that. It really does change your how development workflow -- for the better.
Of course, I know there is no convincing anyone who is a die-hard SVN fan so all I can say is just try Git. There will be a learning curve; it is not as simple as SVN but it is way more powerful.
>> The great thing about it is tagging
SVN's idea of tagging is identical to branching -- it just takes a complete copy (the reason it seems to fast is because it does something similar to copy-on-write, but it is still taking a copy). This means you can do stupid things, like commit code on top of a tag!
>> Hopefully it is as fast as svn in tagging
It's as slow as it takes to write a SHA1 to disk.
>> In svn, it is about 2 seconds
It takes about 2 microseconds in Git, but as Linus alludes in the video I link I posted at the top. Focusing on the time it takes to branch or tag is only half the picture. Ask yourself, when branching how long does it take SVN to merge back a branch? In generally, my experience is it take an awfully long time and often screws up. In git it also takes a few microseconds (as long as it takes to update a SHA1) if you branch has the same parent as the branch you are merging with (99% of the time). For disconnected merges it still generally takes a second or so.
>> The nasty thing about svn is it allows you to unknowingly wipe out entire project trees
Git also lets to you do that. Conversely, Git also allows to recover them.
git branch -D foo # kill the branch
git reset --hard HEAD${1} # undo you last action
NB. HEAD${N} is like a command stack and you can revert back to any of them, even after a destructive action.
>> I haven't tried git yet
Try it. I can almost guarantee that once you've spent a little time learning it (it is quite different from SVN in a number of areas so there is a little bit of a learning curve) you will wonder who on earth you suffered SVN for so long.
Incidentally, if your company insists on using SVN, that's fine cos Git allows you to treat an SVN repo as just another Git repo. You can clone your SVN repo, work in your own Git clone and then push your changes when you are happy with then. The thing with Git is that it's so flexibly it can accommodate nearly all workflows, even those that use other repos.
>> What is your experience with the transition to the chosen Version Control System?
Great idea, I'll contribute a little later (really gotta go do some work now!).
Before I started using Git I felt exactly the same way; then I actually tried using it. Initially I was like, wooah, this is a little complex. Once I got past that stage I realised just how powerful and flexible Git is and how it makes SVN look and feel like a dinosaur. I could never go back to using SVN now. Even if I do have to work with an SVN repo I do so via Git.
The thing is that Git has soooo many powerful features that, until you've actually worked with it for a while and learnt them, you just don't realise what you've got your hands on. It's easy to dismiss Git as just another VCS but it is so much more than that. It really does change your how development workflow -- for the better.
Of course, I know there is no convincing anyone who is a die-hard SVN fan so all I can say is just try Git. There will be a learning curve; it is not as simple as SVN but it is way more powerful.
>> The great thing about it is tagging
SVN's idea of tagging is identical to branching -- it just takes a complete copy (the reason it seems to fast is because it does something similar to copy-on-write, but it is still taking a copy). This means you can do stupid things, like commit code on top of a tag!
>> Hopefully it is as fast as svn in tagging
It's as slow as it takes to write a SHA1 to disk.
>> In svn, it is about 2 seconds
It takes about 2 microseconds in Git, but as Linus alludes in the video I link I posted at the top. Focusing on the time it takes to branch or tag is only half the picture. Ask yourself, when branching how long does it take SVN to merge back a branch? In generally, my experience is it take an awfully long time and often screws up. In git it also takes a few microseconds (as long as it takes to update a SHA1) if you branch has the same parent as the branch you are merging with (99% of the time). For disconnected merges it still generally takes a second or so.
>> The nasty thing about svn is it allows you to unknowingly wipe out entire project trees
Git also lets to you do that. Conversely, Git also allows to recover them.
git branch -D foo # kill the branch
git reset --hard HEAD${1} # undo you last action
NB. HEAD${N} is like a command stack and you can revert back to any of them, even after a destructive action.
>> I haven't tried git yet
Try it. I can almost guarantee that once you've spent a little time learning it (it is quite different from SVN in a number of areas so there is a little bit of a learning curve) you will wonder who on earth you suffered SVN for so long.
Incidentally, if your company insists on using SVN, that's fine cos Git allows you to treat an SVN repo as just another Git repo. You can clone your SVN repo, work in your own Git clone and then push your changes when you are happy with then. The thing with Git is that it's so flexibly it can accommodate nearly all workflows, even those that use other repos.
>> What is your experience with the transition to the chosen Version Control System?
Great idea, I'll contribute a little later (really gotta go do some work now!).
ASKER
Thanks everyone for your thoughts.
Points were awarded to the first comment to everyone who shared their VCS usage experience.
Points were awarded to the first comment to everyone who shared their VCS usage experience.
ASKER
Tech Talk: Linus Torvalds on git
http://www.youtube.com/watch?v=4XpnKHJAok8
That and the plethora of praise others in my team were pouring on it.