State of Hg-SVN vs Git-SVN

[Bryan Murdock]

On Wed, Apr 15, 2015 at 5:28 PM, Charlie Gallo <Charlie at thegallos.com> wrote:
> Hi Gang,
> I'm in an "Interesting" position.
>
> I'm  about  to  start  a  new  role where I'm going to get to make the
> technology decisions for the future team.
>
> Right  now, the existing source control system is SVN, and for various
> political  reasons,  I  don't think it would be a good idea to make an
> IMMEDIATE  jump to Hg or GIT - but as I will be working remote a large
> percentage of the time, having a DSCS is a big deal for me
>
> My plan is to either use Hg-SVN or GIT-SVN
>
> Here is my problem - deciding which
>
> It  has  been  a long time since I've used Hg-SVN, and I've never used
> GIT-SVN.
>
> I prefer Hg to Git, (fits the way I work better) BUT, and it is a huge
> but, with Microsoft's support of Git inside Visual Studio 2013 and
> later  (and  TFS - which I don't love) there are some strong points to
> be made for Git (basically, making it easier/Microsoft's 'support')
>
> Anyone  on  the  group  have experience with both?  Pros/cons.  One of
> those times where I have to look at a bigger picture than just which I
> like  better (Hg) and have to look at "which is better for the company
> in the long run"

I was recently forced to use svn and so I have been using hgsbuversion
in order to cope.  It works fairly well, depending on your svn setup
and needs.  The svn repo I'm using has svn:externals defined and that
gives hgsubversion a hard time.  From what I read, however, git-svn
doesn't support externals at all (but a number of people have written
some scripts to deal with that shortcoming).  For hgsubversion I found
the best solution was to *not* tell it to use subrepos and to remember
to always run hg svn updateexternals after every hg update (or
equivalent) command.  Subversion supports relative paths to externals
but hgsubversion seems to only understand fully-qualified paths, not
relative paths.

Other than the externals caveats, hgsubversion has no support for svn
tags (maybe because they aren't really tags?) and it cannot merge svn
branches (can anything?  I kid...).  I don't know if git-svn does
better with those two things.

The last thing to be aware of is that you are required to rebase your
local commits on top of others svn commits before you can push, to
keep a linear svn-accommodating history.  Again, I don't know how
git-svn works in this regard, but it's hard to image it working any
other way.

One really interesting thing is that your hgsbuversion clone (which,
remember, contains the whole repository history) will probably be
smaller in size than your svn working copy.  Apparently svn keeps a
large amount of metadata in that working copy.  Sorry, don't know
about git-svn on this issue either.

Bryan