Op 22 jul. 2017 03:00 schreef "Nico Kadel-Garcia" <nka...@gmail.com>:
On Thu, Jul 20, 2017 at 5:38 PM, Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >> >> Not wanting to start a flame war, but for all svn users and admins out >> there that sometimes need to have this conversation ... I found this to be a >> very nice website: >> >> https://svnvsgit.com >> >> (I'm not affiliated with the website, just ran into it) > > > Thank you! Thank you! Thank you! > > I did recently have this conversation and this website could have helped > significantly. Sadly, it's not a balanced analysis. It's a "why all the news about Donald Trump is faked by the liberla media, according to Fox News" sort of analysis. I disagree. I rather find the gazillion other comparisons that promote git out there falling into this category. I think this is a welcome change of perspective. But anyway, let he who is without bias cast the first stone ... Balancing information would include "Can Subversion or git delete dangerously or accidentally committed bulky or security sensitive content from the repository?" This is the longest requested feature of Subversion, and there remains no sign of it eve rhappening. If you've ever accidentally committed a file with customer passwords, or a bulky .iso image or core file to a working repository and seen your central repository grow by half a Gigabyte in a single automated commit, you'll know *exactly* what I mean. And even if committed to a branch, it's very difficult to clear from Subversion, and *far* simpler to clear entirely from a git repository. Yeah, well, we know the lack of 'obliterate' is one of your favourite complaints about svn. I am not bothered by it at all, and so are many other svn users. But okay. You do realise git repositories get cloned, right? So once your password file or iso gets pulled / pushed it will be very hard to obliterate ... It's distributed VC after all, so you have a lot more repositories to worry about than just one. > There seem to be some comparisons out there that are comparing DVCSs against > ancient versions of Subversion. Probably those comparisons are old and > therefore their argument may have been valid at the time. But if those > comparisons are more recent, then there's a problem. Either the person > making the comparison is honestly unaware of progress made in Subversion's > development over the years, or they are deliberately comparing to old > versions to make Subversion look bad. Or they are actually looking at problems that are not the ones listed on that webpage. The need for constant network access to the Subversion master for making branches and changes, for example, makes a continuous integration and continuous development entirely dependent on that single component. Local testing branches cannot be stored locally with change history. Okay, your other criticism is lack of local commits, which was also made by some other people in this thread, and that's certainly an area where svn needs to improve. As Branko already said, work is being done for this, as we speak. So if you're interested and want to share your ideas about how this should work in Subversion, hop over to dev@ and give your thoughts. There are some google docs written by Julian Foad with design ideas, UI proposal etc, for 'shelving' and 'checkpointing' (which may be a first step towards local commits). Just search the dev@ archives for the last couple of weeks ... input welcome. -- Johan