Op 22 jul. 2017 03:00 schreef "Nico Kadel-Garcia" <nkadel_at_gmail.com>:
On Thu, Jul 20, 2017 at 5:38 PM, Nathan Hartman
<hartman.nathan_at_gmail.com> wrote:
> On Thu, Jul 20, 2017 at 3:41 PM, Johan Corveleyn <jcorvel_at_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
Received on 2017-07-22 12:06:39 CEST