sync certainly works with git as well. --Mark _______________________ Mark E. Anderson <e...@emer.net>
On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt <ryandes...@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@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev >
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev