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
