Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)

[Rainer Müller]

On 2014-03-16 19:42, Sean Farley wrote:
> If MacPorts really wants to switch to distributed version control, then
> I would suggest Mercurial. I have experimented with using Mercurial for
> the MacPorts repo and found that the mercurial UI is much, much more
> consistent than git coming from Subversion.

I definitely don't want to start a discussion whether git or Mercurial
is the better tool, but they both other integration to Subversion with
git-svn [1] and hgsubversion [2].

I propose we change to our policies to make it possible to work with any
tool locally, giving developers the choice to work with the tool they
like the most, be it svn, git-svn, hgsubversion, bzr-svn, ...

For example, both LLVM [3] and WebKit [4] keep Subversion as their main
repository, but also encourage contributors to use git to prepare patches.

In a perfect world, that would already be possible out of the box, for
example working against our existing Git mirror of the MacPorts
repository [5]. Unfortunately, these tools have some shortcomings that
make working with our current ports tree impossible. The problems are
the missing support for Subversion properties.


a) No support for svn:ignore property

  Easy to accomplish, we would just keep the equivalent in .gitignore
  and .hgignore files in the repository root. The svn:ignore property
  would still be the authoritative value. As these are barely set at
  all in the ports tree, that should not be a problem.


b) No support for svn:keywords property

  Most notably we are using svn:keywords to replace the $Id$ string in
  every Portfile. I think this string is of limited use and we could do
  without it.

  See also this ticket for a detailed discussion of the problem:
  http://trac.macports.org/ticket/38902

  (Following the comments in the ticket,  it's not even an issue with
  newer versions of git-svn any more. What about hgsubversion?)


c) No support for svn:eol-style property

  Do we need that at all, anyway? I don't think anybody is editing this
  on Windows, so I doubt we would ever see a file with CRLF line
  endings.


d) Optional, nice to have: mapping usernames to real names

  Both git and Mercurial usually display real names with email
  addresses instead of plain usernames. A file with that mapping can be
  used, but has to be kept in sync (or can be generated from the wiki).

  At the moment our git mirror uses "<handle>@macports.org@<UUID>" as
  committer. This correctly identifies the person, but is not very nice.


e) Optional, nice to have: split base, doc, www, and ports tree

  With the current git mirror everyone interested in the ports tree is
  also required to fetch the trees for base/, doc/ and doc-new/, and
  www/.

  This is not about disk space as a git clone with full history
  actually takes less space than a Subversion working copy, but a
  separate repository might be easier to handle, especially when you
  can just add that to sources.conf. Note we already have contrib/ and
  users/ as separate repositories.


Any other issues that you might have experienced that I forgot?
Who is already using git-svn, hgsubversion, or similar tools for working
with the ports tree?

Rainer

[1]
https://www.kernel.org/pub/software/scm/git/docs/git-svn.html#_basic_examples
[2] http://mercurial.selenic.com/wiki/HgSubversion
[3] http://llvm.org/docs/GettingStarted.html#git-mirror
[4] http://trac.webkit.org/wiki/UsingGitWithWebKit