Move part of macports infrastructure to GitHub

Mark Anderson emer at emer.net
Thu Mar 20 16:27:49 PDT 2014


sync certainly works with git as well.

--Mark
_______________________
Mark E. Anderson <emer at emer.net>


On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On Mar 20, 2014, at 02:46, Mojca Miklavec wrote:
>
> > Despite the fact that I kept pushing a couple of other projects to
> > switch to a different version control system (mostly from CVS to git),
> > MacPorts is one of those projects where the current system (trac with
> > nice linking between tickets and commits, subversion, buildbots, email
> > accounts, ...) works pretty well and also looks nice. I do miss some
> > functionality (like a website with a nice overview of packages with
> > their build success, latest few commits etc.), but that isn't
> > something that a migration can solve.
>
> Right, that's something improving the MacPorts web site should solve.
>
>
> > Subversion actually has a bunch of benefits over git in this
> > particular environment. Git is strong in merging, cherry-picking,
> > having a large number of branches etc., but I don't see much need for
> > that for maintaining Portfiles. The biggest problem with Portfiles is
> > that a number of people without commit rights might need to wait for a
> > long time before someone picks up their patch and commits it, but
> > switching to a different system would still mean that someone would
> > need to look at commit and test it before accepting it. The only thing
> > that could be different is probably a clearly visible pull request. In
> > MacPorts' trac it's not too easy to spot the difference between
> > "please commit this, it's fully functional" vs. "I've been just
> > playing around and tossing ideas - feel free to look and this patch
> > and improve it" vs. plain requests to fix things. And if a random
> > developer just happens to have time and is willing to test and commit
> > something, it's not clear in which of the thousands of open tickets to
> > start looking. (Trac searches and browsing through tickets based on
> > specific criteria could be improved, but I'm not sure how.)
>
> Such a person should search for tickets with the "haspatch" keyword; that
> keyword should probably only be used for patches that are ready to go.
>
>
> https://trac.macports.org/query?status=!closed&keywords=~haspatch&desc=1&order=id
>
>
> > That said, a git/hg mirror on GitHub/ButBucket would definitely be
> > nice.
>
> Why would that be nicer than the read-only git mirror that Mac OS Forge
> already provides here:
>
> http://www.macosforge.org/post/git-mirrors/
>
>
> > MacPorts could potentially offer a "selfupdate" from an
> > arbitrary git/hg repository clone if necessary (but one can already
> > have a clone on the filesystem and use that one).
>
> selfupdate uses rsync only.
>
> sync can use rsync or svn, possibly other version control systems already,
> I don't remember.
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140320/3d98920c/attachment.html>


More information about the macports-dev mailing list