Re: Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)
On Mar 16, 2014, at 17:18, Rainer Müller wrote: 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. Agreed. To Clemens’ point that these could get out of sync, a pre-commit hook on the Subversion server could ensure that they are not out of sync (or else block the commit, with a message telling the user how to make them sync). 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?) Agreed, we could get rid of the $Id$ line and stop using svn:keywords. 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. We want our text files to have only LF line endings—not CRLF line endings, and certainly not a mix of LF and CRLF line endings. I don’t know if anyone uses an editor that defaults to other than LF line ending styles, but I don’t want to find out about it after a lot of bad commits have already been made. svn:eol-style is enforced on the client side. To prevent problems caused by clients that don’t do this, we could write a pre-commit hook to enforce this in the repository. A hook to enforce that the required properties are set was already planned for a long time: https://trac.macports.org/ticket/12594 The idea to write a hook to prevent non-respected properties is here: https://trac.macports.org/ticket/38902 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)
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
Re: Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)
Hi, I'd like to chime in and offer my $.02. I'll try to keep it brief though, because nobody wants to read thousands of large opinionated posts in this thread if it's supposed to go somewhere. I think the popularity gives git the clear advantage over mercurial or any of the other systems. Also, recent versions of OS X ship with git in the command line tools, but it doesn't seem hg is in that package. Since one possible advantage of git would be to efficiently sync the ports tree using git, I think that gives git a clear advantage. 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, ... While I like the idea of that, I'm not sure it's really going to work well in the long run. We already have a number of people committing changes from mercurial or git-svn and especially the keywords keep getting mixed up on those. 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. I'd like to make a point against doing that. Keeping ignores in multiple files will only cause them to get out-of-sync. Some of the ignores in svn:ignore will sooner or later be committed as .gitignore files (to the SVN repository!), by oversight or on purpose. That's going to become a mess I'd like to avoid. b) No support for svn:keywords property c) No support for svn:eol-style property I agree we should drop those completely. d) Optional, nice to have: mapping usernames to real names If we'd move to a different VCS completely, we'd only have to get this right once. I don't think getting all the integration right in every detail is a task we have the manpower to do continuously. e) Optional, nice to have: split base, doc, www, and ports tree Definitely a good idea IMO. In the end I think the easiest way to get this done – if at all – is to choose a single blessed system and have everybody bite the bullet and learn it. In my opinion, that system should be git, just because it's becoming the de-facto standard tool for the job. I know others might be better in some aspects, and some of the internals of git are a little bit weird, but this was about making contribution easier for more people – and git gets that done. In regard to using Github: I don't think Github's issue tracker scales well to our needs. The port field is a must for a MacPorts issue tracker, IMO. I also think it's formatting capabilities are sub-par: try reproducing http://trac.macports.org/ticket/41466 in a Github issue. We could certainly move the wiki, but if we're keeping trac anyway I don't see the point. I've worked with Gerrit and Github and pull requests are definitely the easiest I've seen. However, they lack just in the same way as their tickets do. Please show me where Github has the same features now provided by http://trac.macports.org/report and http://trac.macports.org/query. I don't want MacPorts to be flooded with pull requests to a point where maintainers can no longer find those specific to their ports. Maybe we can instead improve documentation to a point where contributing is really easy – instead of going to Github and clicking pull request after git push, we should give people clear and precise steps to get their patch into $issuetracker. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
