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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
