[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Use of svnserve and Dropbox

From: Andreas Krey <a.krey_at_gmx.de>
Date: Fri, 23 Sep 2011 08:00:32 +0200

On Fri, 23 Sep 2011 01:18:28 +0000, David Weintraub wrote:
...
> I'm not a big fan of Git. Tracking patches and diffs is not the same
> as version control,

The track&diff part is in *addition* to version control proper.

> and Git is just not as user friendly or as polished.

Don't make me rant. The svn user interface (at least the one that
is ontopic here, namely the 'svn' CLI) is horrible, mostly due to
the fact that svn only pretends to have branches and doesn't have
tags at all. (It replaces them by a convoluted history tracking, and
by forcing each installation to write commit triggers, respectively.)

...
> I am still not convinced that Git is good in corporate environments.
> In those places, you want a centralized repository and the control it
> gives you.

That is usually not a problem. You just have a central 'blessed' repo, and
what isn't (pushed) there doesn't officially exist. Just like in an svn
setting what is not committed does not exist. (It gets more interesting
when you don't trust your users, with respect to access control, b/c of
the separation between who pushed and what is the author name in the
commits pushed.)

> good. If run a development shop building a proprietary trading
> application for a large financial firm, and a million people have a
> copy of your repository, that's bad.

For one, the million people still have the current source in their
sandboxes which is the most valuable part or the repo, and second,
nothing keeps the bad guy to run svnsync or 'git svn clone' (which
half of your devs are likely to use anyway) to get a repo copy.
'They don't have the repo' is just an illusion.

Andreas
Received on 2011-09-23 08:01:15 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.