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

[Sean Farley]

Rainer Müller <raimue at macports.org> writes:

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

That's fine with me. Just a note that bazaar is pretty much dead, if I
understand correctly.

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

I've worked a lot on integrating missing features into hgsubversion and
will respond below.

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

This is generated with 'hg svn genignore'.

> 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?)

This is orthogonal to hgsubversion and is supported by keyword extension
(bundled with Mercurial for ages).

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

Also bundled with Mercurial for ages.

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

This has been supported in hgsubversion since the beginning. It just
needs an authormap which I provide in my Mercurial repo at
smf.io/macports.

Similarly, I've maintained mergeinfo, tags, branches, etc.

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

Not a bad idea.