On Jun 22, 2012, at 7:03 PM, Alexander Hansen wrote: > On 6/22/12 3:23 PM, Max Horn wrote: >> >> Am 23.06.2012 um 00:07 schrieb David R. Morrison: >> >>> >>> On Jun 22, 2012, at 10:59 AM, Alexander Hansen wrote: >>> >>>> Any thoughts about moving dists/ over to github? >>>> >>>> Even though sourceforge isn't going to close down CVS access, it'd be >>>> nice to move to a more modern system. Plus, for users behind firewalls, >>>> github allows files to be accessed via https--we're doing pretty much >>>> the best we can with proxy support for CVS, but sometimes that's still >>>> blocked. >>>> >>>> And for big updates, like a new OS version, I believe it's easier to >>>> handle a branch to do changes in git than in CVS (I'm not sure about >>>> that, though). >>> >>> This is as good a time as any to think about making such a change, but of >>> course it would take some time to implement (i.e., its not going to be >>> ready for the imminent release of 10.8). >>> >>> The reason I say this is that we would need to write a selfupdate-git >>> function, and work through issues like how it interacts with >>> selfupdate-cvs, whether we are migrating everything or just the most recent >>> tree or trees, etc. etc. >> >> Actually, Daniel Johnson has been working on this: >> <https://github.com/danielj7/fink/tree/selfupdate-git>. In the end, it's a >> matter of committment: DO we *want* to switch to this? Does it pay off for >> Daniel and others to invest blood and tears into it? Because if it's not >> clear whether this work has a good chance of being merged in the end, then >> it's a bit difficult to motivate oneself to work on it... >> >> My stance is clear on this: I *want* selfupdate-git, and I really want to >> stop using CVS for anything. The sooner the better. I'll make our life a lot >> easier. >> > > We could bring Daniel's code into a branch of the official fink > repository so that it would be more likely to be tested. He's got a > github copy of dists/, too, and a script to transfer updates from SF CVS > to that. >
I don't have a script per se, I run "git cvsimport -avk -o master" to pull in the latest updates, but with carefully chosen default settings. > >> While I am at it, I'd also like to see us switch to the new dpkg / apt etc. >> ;) I think it was Sjors who worked on that. >> > > My understanding is that Justin Hallet is interested in looking at them, > too, near-term. In my testing of them, there remained an issue with > update-alternatives (that's referenced in my message from yesterday), > but I think they would be good to go as updates if that were fixed--or > we could try the latest upstream versions, even. At that point we could > look into bootstrapping using them. > >> >> >> As for whether to host git repositories. on SF.net or github: that's a >> mostly irrelevant question. We can easily host on both. It's a trivial >> matter to switch between them. But github offers so many useful features >> that SF.net misses that it's not even a close contest. Add in the fact that >> SF.net tends to leave bug reports and feature requests untended for years in >> a row, then closes them saying "we are now deprecating this function" etc., >> makes me not want to host *anything* anymore on SF.net unless I have no >> other choice. >> >> But that's just me. If others want to host git repositories on SF.net (or >> bitbucket, or gitorious, or Google Code, or on a private server, or, or, >> or), that's all fine by me -- after all, one of the big advantages of DVCS >> like git and mercurial is that everybody gets a full copy of the repository; >> and which repository is the "upstream" of which other repository is >> something that can be changed in a blink of an eye ;). >> >> >> Cheers, >> Max >> > > I believe the notion was that once we switched to git (for whatever > subset of platforms) we wouldn't continue to support upgrading via CVS > at all: basically users would selfupdate, and then > Fink::Selfupdate::CVS would tell them that CVS is done and give them a > dialog giving them the option to switch to rsync, https, svn or git. > > (Does that answer the issue of interaction with selfupdate-cvs?) > > Assuming that we want to do some testing ;-), then what we could do is: > > 1) Set up an official selfupdate-git branch of fink by importing > Daniel's code. > 2) Set up a quasi-official dists/ . > 3) Assuming that the test period is going to be longer than we'd be > willing to freeze distribution updates, set up a cron job on phinch to > run Daniel's script or something like it to keep the github dists/ in > sync with sf.net CVS so that it stays fresh while we test (e.g. so that > selfupdate actually does something). > 4) Set an approximate date to convert over to git. > 5) Once we're happy with the operation, then we release a fink that > enables git and disables cvs. > > As to what trees to migrate: there would be some utility in _not_ > migrating the 10.4 tree. 10.7 is the first OS X version where git ships > with Xcode. This was a motivation to provide selfupdate-svn, since svn > is available on 10.5 and later. That would entail OS version tests in > CVS.pm, but I guess those aren't too bad, and they could go away when we > finally kill off 10.6 (Yay for single architecture! Maybe!). > > On the other hand, that would introduce the complexity of having to > update packages in two separate VCSes, which will make syncing between > trees that much harder, and that much less likely. I also have selfupdate-svn code that uses Github's git to svn bridge, but the last time I tested it svn failed to checkout. I'm not sure why as it used to work fine. Maybe some backend change made by Github broke something. I'll have to play with it again. Trying to maintain our own svn mirror would introduce a lot more complexity if we can't rely on Github's bridge. As far as which trees to import, I'd say import all of them and then delete the unused ones from HEAD. That way they wouldn't clutter the working directory but the history would still be accessible. My mirror currently has everything back to 10.2 since I don't know what cvsimport would do if I deleted the old ones. Also, as far as using git with sf.net versus Github, the main difference is that sf.net only does git using the git:// protocol which would not work over proxies, while Github supports git://, http://, https:// and ssh://. That and Github's online tools for managing repos are nicer. It would certainly be possible and even desirable to keep a mirror on sf.net. bitbucket.org also does git hosting in addition to mercurial, with which it is more commonly associated. There is also gitorious and a few others. Daniel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
