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