State of Hg-SVN vs Git-SVN

[Steve Borho]

On 04/15, Bryan Murdock wrote:
> 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')

not to toot our own horn too much, but my company has recently announced
a new plugin for VisualStudio for Mercurial which aims to plug this gap
long term. The plugin is GPL but has a small cost per developer to cover
development and maintenance.

https://hgvs.multicorewareinc.com/

> > 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.

that's no metadata, svn keeps a copy of the each "working parent" file
to prevent 'svn diff' from having to talk to the server. So the working
copy is literally doubled.

-- 
Steve Borho