Subversion is a mess : A Rant in E Minor
-
"Livin' on a Prayer" is in E minor... and that title is a fair description of some of the source control setups I've used.
+5 for referencing a rock classic. Used to play that in pubs, in the throes of my callow youth...
I too dabbled in pacifism once.
-
I used to like Subversion, I really did. But these days it seems to take commands and do what it elephanting well likes with them. Wilfully ignoring subdirectories, deleting files... it knows no end. The new version is painfully inadequate, and buggy to the point of criminality. I too was annoyed by the .svn folders and irked by developers who copied folders around because they didn't want to bother learning how to use the VCS, but removing them has made everything much, much worse. If this is what we get when an open-source project gets too big for its boots, then kill open source. Make them Pay, and deliver a working product. Our options now for version control system run thusly: VSS X| SVN :wtf: What happened to this once-fine product? Git: good but SVN-heads don't want to learn it (and why should they have to?) TFS: Expensive and slow Mercurial probably the best option but see points re: git. I had come to depend on SVN, as I suspect a lot of people have, as a no-nonsense product for a no-nonsense task, which should be taking up about 5% at most of my office time. I've just spent a full day digging through merges and re-adding folders that should never have been ignored. Dropping in files from the filesystem like a noob because SVN has no idea where they are. It makes an elephanting mockery of the whole process. I might just go back to using a freakin neanderthal filesystem-based backup process, until (insert major bank here) decide to approve the use of Mercurial/Git for internal projects. This is unholy. I am angry. [EDIT] I wish to point out that I realise I am treating a freely available product like a commercial app, but in my view, this new insanity really is too much. If they're going to change it, can't they do it right? Why persecute legions of people who have come to rely on it? Who wins?
I too dabbled in pacifism once.
Count me among those who've been using Subversion 1.7.x for some time now, since not long after it came out, without any of the problems you've described here. In fact, use of 1.7 actually made many of our merges run smoother than was the case using 1.6 an previous. We also use TSVN and AnkhSVN for everyday developer style activities, and while Ankh still has some issues with regard to renaming, as mentioned by another poster, the only issues I've had with TSVN are mostly around how long it takes to update the status markers. I understand the reasons for that, but it's still a little annoying. Have you discussed your problems with the Subversion developers, or at least on the user mailing list?
Currently reading: "The Prince", by Nicolo Machiavelli
-
In my experience, free stuff is only free if your time has no value :)
____________________________________________________________ Be brave little warrior, be VERY brave
-
I used to like Subversion, I really did. But these days it seems to take commands and do what it elephanting well likes with them. Wilfully ignoring subdirectories, deleting files... it knows no end. The new version is painfully inadequate, and buggy to the point of criminality. I too was annoyed by the .svn folders and irked by developers who copied folders around because they didn't want to bother learning how to use the VCS, but removing them has made everything much, much worse. If this is what we get when an open-source project gets too big for its boots, then kill open source. Make them Pay, and deliver a working product. Our options now for version control system run thusly: VSS X| SVN :wtf: What happened to this once-fine product? Git: good but SVN-heads don't want to learn it (and why should they have to?) TFS: Expensive and slow Mercurial probably the best option but see points re: git. I had come to depend on SVN, as I suspect a lot of people have, as a no-nonsense product for a no-nonsense task, which should be taking up about 5% at most of my office time. I've just spent a full day digging through merges and re-adding folders that should never have been ignored. Dropping in files from the filesystem like a noob because SVN has no idea where they are. It makes an elephanting mockery of the whole process. I might just go back to using a freakin neanderthal filesystem-based backup process, until (insert major bank here) decide to approve the use of Mercurial/Git for internal projects. This is unholy. I am angry. [EDIT] I wish to point out that I realise I am treating a freely available product like a commercial app, but in my view, this new insanity really is too much. If they're going to change it, can't they do it right? Why persecute legions of people who have come to rely on it? Who wins?
I too dabbled in pacifism once.
I am interested in everyone's issues with VSS. I have been extremely happy with its simplicity since the mid 90's. I would like to hear some real technical feedback on the basis of your opinions. I am being serious here, can anyone articulate a real issue? I suppose it would have to be an issue that's limited only to VSS, that is, you cant say "A lack of support for atomic commits for multiple files" -- when that is a problem with nearly all source control systems. Interested in you professional opinions here... thanks. I am not a Microsoft Fan boi, I just prefer simple, un-obtrusive, easy to admin version control.
Where there's smoke, there's a Blue Screen of death.
-
I used to like Subversion, I really did. But these days it seems to take commands and do what it elephanting well likes with them. Wilfully ignoring subdirectories, deleting files... it knows no end. The new version is painfully inadequate, and buggy to the point of criminality. I too was annoyed by the .svn folders and irked by developers who copied folders around because they didn't want to bother learning how to use the VCS, but removing them has made everything much, much worse. If this is what we get when an open-source project gets too big for its boots, then kill open source. Make them Pay, and deliver a working product. Our options now for version control system run thusly: VSS X| SVN :wtf: What happened to this once-fine product? Git: good but SVN-heads don't want to learn it (and why should they have to?) TFS: Expensive and slow Mercurial probably the best option but see points re: git. I had come to depend on SVN, as I suspect a lot of people have, as a no-nonsense product for a no-nonsense task, which should be taking up about 5% at most of my office time. I've just spent a full day digging through merges and re-adding folders that should never have been ignored. Dropping in files from the filesystem like a noob because SVN has no idea where they are. It makes an elephanting mockery of the whole process. I might just go back to using a freakin neanderthal filesystem-based backup process, until (insert major bank here) decide to approve the use of Mercurial/Git for internal projects. This is unholy. I am angry. [EDIT] I wish to point out that I realise I am treating a freely available product like a commercial app, but in my view, this new insanity really is too much. If they're going to change it, can't they do it right? Why persecute legions of people who have come to rely on it? Who wins?
I too dabbled in pacifism once.
In the last week I've done some research on Git and Mercurial and downloaded them both. For what it's worth, Linus Torvalds said in his 2007 Google presentation that only 2 source control systems were worthy of anyone's attention, those two being Git and Mercurial. He hates SVN. I've read in a lot of other places that SVN is out of favour these days. For myself, I've not used it, having only used an old version of MS Visual SourceSafe in the past, but I really like the model of distributed version control and have gone for Mercurial. In a distributed system, you typically create a separate repository on your local machine in your project folder so you'll have a separate one for each project. You can make fast commits (check-ins) to your local repository whenever you want and only push your changes to a shared repository or someone else when you are happy that the code is stable enough to share. That takes care of the dilemma about whether to check in stuff that doesn't work properly yet or just do without source control while trying out new ideas in the code. When you create a Mercurial repository, it adds a subfolder called .hg to the folder you choose, which is where it keeps its data. After your initial commit, Mercurial knows which files have since been added, changed or removed and you can easily tell it to ignore files and subfolders eg your build folders. Each time you commit, it takes a complete snapshot of the folder content and its structure so your are free to move folders around and make whatever changes you want. Therefore no need to worry about your local folder structure being different from the one in source control. I chose Mercurial over Git because Git is made up of several different programs that interact and I prefer mercurial's monolithic program. Git's Windows support is decent now but Mercurial has always been Windows-friendly, is easy to use and well documented and that's the one I chose for my needs. You can use TortoiseHg for Windows Explorer integration and to see a chart showing branches etc. However, even the command line is straight forward enough if you don't have that.
-
I am interested in everyone's issues with VSS. I have been extremely happy with its simplicity since the mid 90's. I would like to hear some real technical feedback on the basis of your opinions. I am being serious here, can anyone articulate a real issue? I suppose it would have to be an issue that's limited only to VSS, that is, you cant say "A lack of support for atomic commits for multiple files" -- when that is a problem with nearly all source control systems. Interested in you professional opinions here... thanks. I am not a Microsoft Fan boi, I just prefer simple, un-obtrusive, easy to admin version control.
Where there's smoke, there's a Blue Screen of death.
I'm in the same boat. I've been using VSS for over a decade. In fact the company is still using the 6.0 version. We've never had any issues with it. EDIT: Just had a look at Mercurial, and will definitely give it a look. Local branches are just what I was looking for.
"There are only 10 types of people in the world - those who know binary and those who don't."
-
In the last week I've done some research on Git and Mercurial and downloaded them both. For what it's worth, Linus Torvalds said in his 2007 Google presentation that only 2 source control systems were worthy of anyone's attention, those two being Git and Mercurial. He hates SVN. I've read in a lot of other places that SVN is out of favour these days. For myself, I've not used it, having only used an old version of MS Visual SourceSafe in the past, but I really like the model of distributed version control and have gone for Mercurial. In a distributed system, you typically create a separate repository on your local machine in your project folder so you'll have a separate one for each project. You can make fast commits (check-ins) to your local repository whenever you want and only push your changes to a shared repository or someone else when you are happy that the code is stable enough to share. That takes care of the dilemma about whether to check in stuff that doesn't work properly yet or just do without source control while trying out new ideas in the code. When you create a Mercurial repository, it adds a subfolder called .hg to the folder you choose, which is where it keeps its data. After your initial commit, Mercurial knows which files have since been added, changed or removed and you can easily tell it to ignore files and subfolders eg your build folders. Each time you commit, it takes a complete snapshot of the folder content and its structure so your are free to move folders around and make whatever changes you want. Therefore no need to worry about your local folder structure being different from the one in source control. I chose Mercurial over Git because Git is made up of several different programs that interact and I prefer mercurial's monolithic program. Git's Windows support is decent now but Mercurial has always been Windows-friendly, is easy to use and well documented and that's the one I chose for my needs. You can use TortoiseHg for Windows Explorer integration and to see a chart showing branches etc. However, even the command line is straight forward enough if you don't have that.
That is definitely a great reply. Thank you, I learned a lot from that. One comment --> I still don't understand why VSS is so reviled. If someone could articulate the reasons maybe I can be educated away from it.
Where there's smoke, there's a Blue Screen of death.
-
Some years ago (after overbearing massive resistances within the team) I've successfully changed the Version Control System from VSS to SVN. My conclusion is: Who don't want to use SVN (in this case the reason is: it's not Microsoft) does all to discredit the system. They work with local copies and branches in a way they would never do with TFS and cries that nothing will work in SVN. Maximilien is right: The best version control system is useless if inner resistances of some team members prevent them from learning.
-
In the last week I've done some research on Git and Mercurial and downloaded them both. For what it's worth, Linus Torvalds said in his 2007 Google presentation that only 2 source control systems were worthy of anyone's attention, those two being Git and Mercurial. He hates SVN. I've read in a lot of other places that SVN is out of favour these days. For myself, I've not used it, having only used an old version of MS Visual SourceSafe in the past, but I really like the model of distributed version control and have gone for Mercurial. In a distributed system, you typically create a separate repository on your local machine in your project folder so you'll have a separate one for each project. You can make fast commits (check-ins) to your local repository whenever you want and only push your changes to a shared repository or someone else when you are happy that the code is stable enough to share. That takes care of the dilemma about whether to check in stuff that doesn't work properly yet or just do without source control while trying out new ideas in the code. When you create a Mercurial repository, it adds a subfolder called .hg to the folder you choose, which is where it keeps its data. After your initial commit, Mercurial knows which files have since been added, changed or removed and you can easily tell it to ignore files and subfolders eg your build folders. Each time you commit, it takes a complete snapshot of the folder content and its structure so your are free to move folders around and make whatever changes you want. Therefore no need to worry about your local folder structure being different from the one in source control. I chose Mercurial over Git because Git is made up of several different programs that interact and I prefer mercurial's monolithic program. Git's Windows support is decent now but Mercurial has always been Windows-friendly, is easy to use and well documented and that's the one I chose for my needs. You can use TortoiseHg for Windows Explorer integration and to see a chart showing branches etc. However, even the command line is straight forward enough if you don't have that.
I recently went through a similar evaluation process - with pretty much the same results. Mercurial ended up being the most simple to get working for our Windows-based environment. And the DVSC model means we can still work on projects while onsite at a customer location.
-
I used to like Subversion, I really did. But these days it seems to take commands and do what it elephanting well likes with them. Wilfully ignoring subdirectories, deleting files... it knows no end. The new version is painfully inadequate, and buggy to the point of criminality. I too was annoyed by the .svn folders and irked by developers who copied folders around because they didn't want to bother learning how to use the VCS, but removing them has made everything much, much worse. If this is what we get when an open-source project gets too big for its boots, then kill open source. Make them Pay, and deliver a working product. Our options now for version control system run thusly: VSS X| SVN :wtf: What happened to this once-fine product? Git: good but SVN-heads don't want to learn it (and why should they have to?) TFS: Expensive and slow Mercurial probably the best option but see points re: git. I had come to depend on SVN, as I suspect a lot of people have, as a no-nonsense product for a no-nonsense task, which should be taking up about 5% at most of my office time. I've just spent a full day digging through merges and re-adding folders that should never have been ignored. Dropping in files from the filesystem like a noob because SVN has no idea where they are. It makes an elephanting mockery of the whole process. I might just go back to using a freakin neanderthal filesystem-based backup process, until (insert major bank here) decide to approve the use of Mercurial/Git for internal projects. This is unholy. I am angry. [EDIT] I wish to point out that I realise I am treating a freely available product like a commercial app, but in my view, this new insanity really is too much. If they're going to change it, can't they do it right? Why persecute legions of people who have come to rely on it? Who wins?
I too dabbled in pacifism once.
-
That is definitely a great reply. Thank you, I learned a lot from that. One comment --> I still don't understand why VSS is so reviled. If someone could articulate the reasons maybe I can be educated away from it.
Where there's smoke, there's a Blue Screen of death.
VSS is primarily reviled because no one has worked with for any amount of time in any volume and not had to deal with database corruption, failed restoration operations, user conflicts, problems with multiple checkout, and issues relating to different shell integration packages.
-
TFS: Stable, reliable, built in automation, integrated project management, integrated collaboration and document management, fuzzy dice.
I switched to TFS about a year ago and haven't looked back. It took a few days to get the server working as desired, but it was well worth the hassle. TFS is a great product.
-
I used to like Subversion, I really did. But these days it seems to take commands and do what it elephanting well likes with them. Wilfully ignoring subdirectories, deleting files... it knows no end. The new version is painfully inadequate, and buggy to the point of criminality. I too was annoyed by the .svn folders and irked by developers who copied folders around because they didn't want to bother learning how to use the VCS, but removing them has made everything much, much worse. If this is what we get when an open-source project gets too big for its boots, then kill open source. Make them Pay, and deliver a working product. Our options now for version control system run thusly: VSS X| SVN :wtf: What happened to this once-fine product? Git: good but SVN-heads don't want to learn it (and why should they have to?) TFS: Expensive and slow Mercurial probably the best option but see points re: git. I had come to depend on SVN, as I suspect a lot of people have, as a no-nonsense product for a no-nonsense task, which should be taking up about 5% at most of my office time. I've just spent a full day digging through merges and re-adding folders that should never have been ignored. Dropping in files from the filesystem like a noob because SVN has no idea where they are. It makes an elephanting mockery of the whole process. I might just go back to using a freakin neanderthal filesystem-based backup process, until (insert major bank here) decide to approve the use of Mercurial/Git for internal projects. This is unholy. I am angry. [EDIT] I wish to point out that I realise I am treating a freely available product like a commercial app, but in my view, this new insanity really is too much. If they're going to change it, can't they do it right? Why persecute legions of people who have come to rely on it? Who wins?
I too dabbled in pacifism once.
All good points…what I might be tempted to do if I were you is to use Mercurial (purely because it is slightly more Windows friendly, and my head works better with it) and use hgsubversion to use hg as your SVN client… Basically, after installing the hg-svn, you can clone an SVN repository into an hg one, then use hg locally and then when you're ready, push from hg back to the SVN repository - i.e. the push is equivalent to an SVN commit… More details here… PS - we use SVN at work…I prefer hg…I'm more than likely going to give the above a go on the next project I work on…
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p CodeProject MVP for 2010 - who'd'a thunk it!
-
In the last week I've done some research on Git and Mercurial and downloaded them both. For what it's worth, Linus Torvalds said in his 2007 Google presentation that only 2 source control systems were worthy of anyone's attention, those two being Git and Mercurial. He hates SVN. I've read in a lot of other places that SVN is out of favour these days. For myself, I've not used it, having only used an old version of MS Visual SourceSafe in the past, but I really like the model of distributed version control and have gone for Mercurial. In a distributed system, you typically create a separate repository on your local machine in your project folder so you'll have a separate one for each project. You can make fast commits (check-ins) to your local repository whenever you want and only push your changes to a shared repository or someone else when you are happy that the code is stable enough to share. That takes care of the dilemma about whether to check in stuff that doesn't work properly yet or just do without source control while trying out new ideas in the code. When you create a Mercurial repository, it adds a subfolder called .hg to the folder you choose, which is where it keeps its data. After your initial commit, Mercurial knows which files have since been added, changed or removed and you can easily tell it to ignore files and subfolders eg your build folders. Each time you commit, it takes a complete snapshot of the folder content and its structure so your are free to move folders around and make whatever changes you want. Therefore no need to worry about your local folder structure being different from the one in source control. I chose Mercurial over Git because Git is made up of several different programs that interact and I prefer mercurial's monolithic program. Git's Windows support is decent now but Mercurial has always been Windows-friendly, is easy to use and well documented and that's the one I chose for my needs. You can use TortoiseHg for Windows Explorer integration and to see a chart showing branches etc. However, even the command line is straight forward enough if you don't have that.
computer_nerd wrote:
only 2 source control systems ... He hates SVN.
Probably because Subversion isn't a source control system; it's a document control system. In my opinion (and having used it for source control for a year and a half now), it is unsuited for source control in that it lacks features that may be unique to source files (mainly ways of grouping files into logical units).
computer_nerd wrote:
I really like the model of distributed version control
I don't think I would, but I haven't tried it yet.
-
Git.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyI would go with Mercurial and tortoisehg instead. I use git at work and mercurial for personal projects and they are essentially the same, but mercurial stays out of my way more... Git isn't bad, but there are usability issues like having to add new files before a commit or having to pull/merge/push instead of having it just create unnamed branches and letting me merge them when I feel like it. I don't really miss having to deal with local VS public branches when using mercurial. And if we could just figure out some way of having tortoisegit remember our usernames/passwords, using it would be much more enjoyable.
-
I used to like Subversion, I really did. But these days it seems to take commands and do what it elephanting well likes with them. Wilfully ignoring subdirectories, deleting files... it knows no end. The new version is painfully inadequate, and buggy to the point of criminality. I too was annoyed by the .svn folders and irked by developers who copied folders around because they didn't want to bother learning how to use the VCS, but removing them has made everything much, much worse. If this is what we get when an open-source project gets too big for its boots, then kill open source. Make them Pay, and deliver a working product. Our options now for version control system run thusly: VSS X| SVN :wtf: What happened to this once-fine product? Git: good but SVN-heads don't want to learn it (and why should they have to?) TFS: Expensive and slow Mercurial probably the best option but see points re: git. I had come to depend on SVN, as I suspect a lot of people have, as a no-nonsense product for a no-nonsense task, which should be taking up about 5% at most of my office time. I've just spent a full day digging through merges and re-adding folders that should never have been ignored. Dropping in files from the filesystem like a noob because SVN has no idea where they are. It makes an elephanting mockery of the whole process. I might just go back to using a freakin neanderthal filesystem-based backup process, until (insert major bank here) decide to approve the use of Mercurial/Git for internal projects. This is unholy. I am angry. [EDIT] I wish to point out that I realise I am treating a freely available product like a commercial app, but in my view, this new insanity really is too much. If they're going to change it, can't they do it right? Why persecute legions of people who have come to rely on it? Who wins?
I too dabbled in pacifism once.
I haven't updated SVN/TSVN/AnkhSVN since I last set them up together with VS 2010 about a year ago. And I would make sure to update them all together, if at all, and then only when I get my colleages to do so as well. That said, as long as I don't see a new function I want or encounter a problem in our current environment, I see no reason to update. As for other systems - I do consider myself what you call a 'SVN-head' ;). Still, I do ask around whenever given a chance, and the best votes I got so far were in favor of Mercurial. It is a different kind of version control though, more targeted for distributed development, whereas I am working in a small, local team. So I see no good reason to switch. On a sidenote, file-backup may indeed be superior to VSS (which has a nasty habit of getting it's database corrupted), but personally I'd prefer using a local SVN frontend and back up the resulting database instead. (you do know that you can create a repository on your own filesystem? It's really fast and doesn't suffer from any problems related to bad or slow network!)