<div dir="ltr">sync certainly works with git as well.</div><div class="gmail_extra"><br clear="all"><div>—Mark<br>_______________________<br>Mark E. Anderson <<a href="mailto:emer@emer.net" target="_blank">emer@emer.net</a>><br>
</div>
<br><br><div class="gmail_quote">On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On Mar 20, 2014, at 02:46, Mojca Miklavec wrote:<br>
<br>
> Despite the fact that I kept pushing a couple of other projects to<br>
> switch to a different version control system (mostly from CVS to git),<br>
> MacPorts is one of those projects where the current system (trac with<br>
> nice linking between tickets and commits, subversion, buildbots, email<br>
> accounts, ...) works pretty well and also looks nice. I do miss some<br>
> functionality (like a website with a nice overview of packages with<br>
> their build success, latest few commits etc.), but that isn't<br>
> something that a migration can solve.<br>
<br>
</div>Right, that’s something improving the MacPorts web site should solve.<br>
<div class=""><br>
<br>
> Subversion actually has a bunch of benefits over git in this<br>
> particular environment. Git is strong in merging, cherry-picking,<br>
> having a large number of branches etc., but I don't see much need for<br>
> that for maintaining Portfiles. The biggest problem with Portfiles is<br>
> that a number of people without commit rights might need to wait for a<br>
> long time before someone picks up their patch and commits it, but<br>
> switching to a different system would still mean that someone would<br>
> need to look at commit and test it before accepting it. The only thing<br>
> that could be different is probably a clearly visible pull request. In<br>
> MacPorts' trac it's not too easy to spot the difference between<br>
> "please commit this, it's fully functional" vs. "I've been just<br>
> playing around and tossing ideas – feel free to look and this patch<br>
> and improve it" vs. plain requests to fix things. And if a random<br>
> developer just happens to have time and is willing to test and commit<br>
> something, it's not clear in which of the thousands of open tickets to<br>
> start looking. (Trac searches and browsing through tickets based on<br>
> specific criteria could be improved, but I'm not sure how.)<br>
<br>
</div>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.<br>
<br>
<a href="https://trac.macports.org/query?status=!closed&keywords=~haspatch&desc=1&order=id" target="_blank">https://trac.macports.org/query?status=!closed&keywords=~haspatch&desc=1&order=id</a><br>
<div class=""><br>
<br>
> That said, a git/hg mirror on GitHub/ButBucket would definitely be<br>
> nice.<br>
<br>
</div>Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here:<br>
<br>
<a href="http://www.macosforge.org/post/git-mirrors/" target="_blank">http://www.macosforge.org/post/git-mirrors/</a><br>
<div class=""><br>
<br>
> MacPorts could potentially offer a "selfupdate" from an<br>
> arbitrary git/hg repository clone if necessary (but one can already<br>
> have a clone on the filesystem and use that one).<br>
<br>
</div>selfupdate uses rsync only.<br>
<br>
sync can use rsync or svn, possibly other version control systems already, I don’t remember.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
macports-dev mailing list<br>
<a href="mailto:macports-dev@lists.macosforge.org">macports-dev@lists.macosforge.org</a><br>
<a href="https://lists.macosforge.org/mailman/listinfo/macports-dev" target="_blank">https://lists.macosforge.org/mailman/listinfo/macports-dev</a><br>
</div></div></blockquote></div><br></div>