From: Earnie B. <ea...@us...> - 2006-02-24 23:53:02
|
Any interest in coverting? <snippet> Subversion General Availability ------------------------------- The SourceForge.net team is pleased to announce the General Availability of Subversion service to SourceForge.net-hosted projects, effective 2006-02-21. This service offering is in addition to our existing CVS service; as with all of our services, projects may select (and enable in the project admin pages) the portion of our offering that best meets their needs. </snippet> May be too early yet. May have coordination problems with Redhat CVS versus Subversion. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Chris S. <ir0...@gm...> - 2011-01-30 05:05:42
|
Hi All, Just a heads up (for those who haven't read it): https://sourceforge.net/blog/sourceforge-attack-full-report/ Looks like SourceForge CVS is going to be down for a while, beyond that, it looks like CVS may be shutdown by SourceForge in the not-to-distant future (in favour of Subversion). Do we bite the bullet now and migrate to Subversion? I realize that this will impact all the work Keith has done with mingw-get, hopefully it can be modified to use Subversion as opposed to CVS. Chris |
From: NightStrike <nig...@gm...> - 2011-01-30 05:23:42
|
On Sun, Jan 30, 2011 at 12:05 AM, Chris Sutcliffe <ir0...@gm...> wrote: > Hi All, > > Just a heads up (for those who haven't read it): > > https://sourceforge.net/blog/sourceforge-attack-full-report/ > > Looks like SourceForge CVS is going to be down for a while, beyond that, > it looks like CVS may be shutdown by SourceForge in the not-to-distant > future (in favour of Subversion). Do we bite the bullet now and migrate > to Subversion? I realize that this will impact all the work Keith has > done with mingw-get, hopefully it can be modified to use Subversion as > opposed to CVS. Subversion has a very complete lib that you can compile into your software. |
From: Luke K. C. L. <lk...@lk...> - 2011-01-30 05:38:36
|
On Sun, Jan 30, 2011 at 5:23 AM, NightStrike <nig...@gm...> wrote: > On Sun, Jan 30, 2011 at 12:05 AM, Chris Sutcliffe <ir0...@gm...> wrote: >> Hi All, >> >> Just a heads up (for those who haven't read it): >> >> https://sourceforge.net/blog/sourceforge-attack-full-report/ >> >> Looks like SourceForge CVS is going to be down for a while, beyond that, >> it looks like CVS may be shutdown by SourceForge in the not-to-distant >> future (in favour of Subversion). Do we bite the bullet now and migrate >> to Subversion? I realize that this will impact all the work Keith has >> done with mingw-get, hopefully it can be modified to use Subversion as >> opposed to CVS. > > Subversion has a very complete lib that you can compile into your software. if sourceforget is running gitorious (or git-daemon) gitorious has a means to create tarballs over http, you can specify the exact revision that you want or you can, i believe, specify a tag or a branch name (or just "master"). you'll have to check what they're running, though. it's late otherwise i'd check on your behalf. l. |
From: Luke K. C. L. <lk...@lk...> - 2011-01-30 05:35:23
|
On Sun, Jan 30, 2011 at 5:05 AM, Chris Sutcliffe <ir0...@gm...> wrote: > Hi All, > > Just a heads up (for those who haven't read it): > > https://sourceforge.net/blog/sourceforge-attack-full-report/ > > Looks like SourceForge CVS is going to be down for a while, beyond that, > it looks like CVS may be shutdown by SourceForge in the not-to-distant > future (in favour of Subversion). Do we bite the bullet now and migrate > to Subversion? I realize that this will impact all the work Keith has > done with mingw-get, hopefully it can be modified to use Subversion as > opposed to CVS. i would strongly recommend git. git-win32 ironically uses mingw as the base :) actually the (ridiculously large) git-win32 install has to slurp in pretty much everything under the sun in it - bash, perl, awk, sed, patch, diff, ssh (!), openssl - the works. why? well, look at git's dependencies and you start to see why. i'm really not sure why they bunged in vim but i'm glad they did. by installing git-win32 i don't need to install anything else for software development on a win32 box! :) svn is not as robust as git, and has a habit of multiplying up the disk space utilised by a factor of... well i heard one kde developer say it was like a 5x increase over the source code, whereas git is just incredibly efficient and stores diffs on diffs on diffs etc. i heard also - i'm not sure if it's true - that it's quicker to do a git checkout than it is to do a tar -xvzf on the exact same source code tree! kde have just moved to git (today i think). by moving to svn you will be moving to a source repository that is losing mindshare just like cvs has lost mindshare. oh, and restricting developers to a server-centric star network based solely and exclusively around sourceforge. by moving to git you will allow developers to decide, easily "sod sourceforget, we go with these guys now", and it's a matter of everyone adding the new git repo to the config file and going git push/pull from that. i've done triple-repository push/pull before now, using git to place repositories in three separate public repositories online, just like that. really. don't use svn :) l. |
From: John E. / T. <td...@td...> - 2011-01-30 06:05:31
|
On 1/29/2011 10:05 PM, Chris Sutcliffe wrote: > Do we bite the bullet now and migrate > to Subversion? I realize that this will impact all the work Keith has > done with mingw-get, hopefully it can be modified to use Subversion as > opposed to CVS. As a complement to Luke's suggestion of using Git, I'd like to strongly recommend Mercurial (hg). I will not and cannot say that it is definitively better than Git, or more appropriate for the MinGW project -- that's a decision for the admins -- but, for anyone working in a Windows environment, it is an easier and more lightweight install. Nothing else needs to be said except that Mercurial and Git are both modern, professional, eminently usable distributed version control systems; a glance at the features and design choices of each would certainly be enough for those responsible to determine whether either is appropriate for the MinGW project and preferable to Subversion. -John E. |
From: Luke K. C. L. <lk...@lk...> - 2011-01-30 15:10:30
|
On Sun, Jan 30, 2011 at 6:05 AM, John E. / TDM <td...@td...> wrote: > On 1/29/2011 10:05 PM, Chris Sutcliffe wrote: >> Do we bite the bullet now and migrate >> to Subversion? I realize that this will impact all the work Keith has >> done with mingw-get, hopefully it can be modified to use Subversion as >> opposed to CVS. > > As a complement to Luke's suggestion of using Git, I'd like to strongly > recommend Mercurial (hg). mmm... but sourceforget (afaik) doesn't support hg. however for "personal" use there exist gateways. i use git-svn deliberately if there is an svn repository about that i can't convert and i need to do commits etc. to it. l. |
From: NightStrike <nig...@gm...> - 2011-01-30 15:31:00
|
On Sun, Jan 30, 2011 at 10:10 AM, Luke Kenneth Casson Leighton <lk...@lk...> wrote: > mmm... but sourceforget (afaik) doesn't support hg. The site's name is "sourceforge". They provide a whole heck of a lot of service for zero dollars, and mocking them is in extremely poor taste. FOSS developers are the first to respond with "Don't be rude to me, I work for free." The same should apply to the company providing very expensive services for nothing. Every one of your emails in this thread is filled with jabs at sourceforge. I, for one, am thankful for what they provide. You should be, as well. That, or petition to move the entire project off the site. And, for the record, "sourceforget" is a terrible play on words. At least try to come up with something worthwhile. |
From: Luke K. C. L. <lk...@lk...> - 2011-01-30 15:40:50
|
On Sun, Jan 30, 2011 at 3:30 PM, NightStrike <nig...@gm...> wrote: > On Sun, Jan 30, 2011 at 10:10 AM, Luke Kenneth Casson Leighton > <lk...@lk...> wrote: >> mmm... but sourceforget (afaik) doesn't support hg. > And, for the record, "sourceforget" is a terrible play on words. At > least try to come up with something worthwhile. peace, dude :) i have 17 projects on sf, the first one i registered was over 10 years ago; one one alioth and another on savannah (both of which are alexandria project-based, like sf, as you're no doubt aware). i missed the hippy era by being 20 years too young but i still feel compelled to say "chill, maaan, it's all goood" :) best, and apologies, l. |
From: John E. / T. <td...@td...> - 2011-01-30 15:47:23
|
On 1/30/2011 8:10 AM, Luke Kenneth Casson Leighton wrote: > mmm... but sourceforget (afaik) doesn't support hg. SourceForge provides complete Mercurial hosting services. -John E. |
From: NightStrike <nig...@gm...> - 2011-01-30 17:00:06
|
On Sun, Jan 30, 2011 at 10:47 AM, John E. / TDM <td...@td...> wrote: > On 1/30/2011 8:10 AM, Luke Kenneth Casson Leighton wrote: >> mmm... but sourceforget (afaik) doesn't support hg. > > SourceForge provides complete Mercurial hosting services. As well as bzr, fwiw |
From: Earnie <ea...@us...> - 2011-01-31 13:06:58
|
John E. / TDM wrote: > On 1/29/2011 10:05 PM, Chris Sutcliffe wrote: >> Do we bite the bullet now and migrate >> to Subversion? I realize that this will impact all the work Keith has >> done with mingw-get, hopefully it can be modified to use Subversion as >> opposed to CVS. > > As a complement to Luke's suggestion of using Git, I'd like to strongly > recommend Mercurial (hg). I will not and cannot say that it is NO! > definitively better than Git, or more appropriate for the MinGW project > -- that's a decision for the admins -- but, for anyone working in a > Windows environment, it is an easier and more lightweight install. We'll end up providing just the git client so that anyone working in a Windows environment can just use that. Unlike msys-git it will only contain the necessary git client tools to add instead of a complete MSYS environment. Earnie |
From: John E. / T. <td...@td...> - 2011-01-31 14:18:41
|
On 1/31/2011 6:06 AM, Earnie wrote: > John E. / TDM wrote: >> As a complement to Luke's suggestion of using Git, I'd like to strongly >> recommend Mercurial (hg). I will not and cannot say that it is > NO! Your project, your rules. I'm sorry you find hg so abhorrent. > We'll end up providing just the git client so that anyone working in a > Windows environment can just use that. Unlike msys-git it will only > contain the necessary git client tools to add instead of a complete MSYS > environment. This is encouraging. -John E. |
From: John E. / T. <td...@td...> - 2011-02-01 01:00:24
|
On 1/31/2011 8:11 AM, Luke Kenneth Casson Leighton wrote: > On Mon, Jan 31, 2011 at 2:18 PM, John E. / TDM<td...@td...> wrote: >> Your project, your rules. I'm sorry you find hg so abhorrent. > john, i can tell you, definitely, it's not "rules", it's sheer > practicality. python really is a bitch to get working under mingw32 - > it's why muggins (me) tackled it. compiling git - actually taking > msys-git and cutting it back drastically (no point reinventing work) - > is a walk in the park by comparison. :S > so it's nothing to do with hg, great as it may be, but having > something like python being _that_ low-level in the dependencies would > be a complete nightmare. Since hg can be (and is, for the Windows build) compiled into a standalone executable within a built-in Python interpreter, I assume you refer to having it as a requirement on the system building MSYS itself? If so -- yes, I can see why that may be undesirable. I approach the topic as a user and hacker who uses MinGW/MSYS because of the large array of free software that it can compile for Windows. As the majority of my development is done in and for the Windows environment, Mercurial has been the vastly superior VCS choice, due in large part to its in-project support for cross-platform interoperability and the native Windows interpreter. Obviously, I'd like to be able to hack on MinGW with the same VCS -- but I don't have the ability (time) or the authority to make that happen. I also don't want to beat the proverbial dead horse, so if my comments cease being constructive please feel free to ignore me. -John E. |
From: Charles W. <cwi...@us...> - 2011-01-30 20:46:36
|
On 1/30/2011 12:05 AM, Chris Sutcliffe wrote: > Just a heads up (for those who haven't read it): > > https://sourceforge.net/blog/sourceforge-attack-full-report/ > > Looks like SourceForge CVS is going to be down for a while, beyond that, > it looks like CVS may be shutdown by SourceForge in the not-to-distant > future (in favour of Subversion). Do we bite the bullet now and migrate > to Subversion? I realize that this will impact all the work Keith has > done with mingw-get, hopefully it can be modified to use Subversion as > opposed to CVS. Yes, I had noticed that there were issues with cvs this weekend; I have an updated mingw-get-inst package that I haven't been able to upload (I also wanted to add mingw-get-inst to the CVS repo, including previous releases in the version history, but was obviously stymied on that). As far as "switching" to another version control system, two points: 1) If sourceforge doesn't support it, mingw won't use it. We have no plans to switch to another source control hosting provider. 2) Sad as it may be, one of the primary requirements for mingw to use a VCS other than CVS, is: do we have a port that is well-integrated with our offerings? Right now, the answer is "no" -- all we have is CVS. (even the "msys-git" alternate distribution is "separate" from *our* offerings; and besides, if I understand correctly "msys-git" is *ACTUALLY* a mingw port of git, which relies on external msys programs...a bit of an odd duck, IMO.) So...for all the clamoring...let me put it this way: put up or shut up. Work on creating an msys (or mingw, but probably msys) port of My-Fav-VCS-Client, *AS WELL AS* all of its dependencies, and package them all according to the mingw-get standards http://www.mingw.org/PackageIdentificationHOWTO And we'll see how that goes. For instance, bzr requires a port of python (which has its own massive list of dependencies). git requires, among many other things, a newer port of perl than our current 5.6.x (perl-5.8.x is actually on my TODO list, but I haven't accumulated enough 'tuits yet, even piggy-backing on msys-git's existing work there. And let's not even think about perl-5.10.x...IMO that's an msys-2.0 project.) SVN requires a port of libneon and a few other libs. Get crackin', then we'll be able to *talk* about switching the official VCS. See, step 1: can we support VCS client foo, for ANY purpose. THEN comes step 2: should we use VCS client foo for official mingw and msys source control. Step 3: how to manage the transition without losing all version history. You guys aren't even at step 1 yet. -- Chuck |
From: Keith M. <kei...@nt...> - 2011-01-30 21:42:53
|
On 30/01/11 20:46, Charles Wilson wrote: > On 1/30/2011 12:05 AM, Chris Sutcliffe wrote: >>> Just a heads up (for those who haven't read it): >>> >>> https://sourceforge.net/blog/sourceforge-attack-full-report/ >>> >>> Looks like SourceForge CVS is going to be down for a while, >>> beyond that, it looks like CVS may be shutdown by SourceForge in >>> the not-to-distant future (in favour of Subversion). Do we bite >>> the bullet now and migrate to Subversion? I realize that this >>> will impact all the work Keith has done with mingw-get, hopefully >>> it can be modified to use Subversion as opposed to CVS. > > Yes, I had noticed that there were issues with cvs this weekend; Not just this weekend: since Wednesday, when some lowlife tried to crack root on one or more of their servers. They've pulled the plug on CVS, project shell and file upload services while they shore up the holes and assess the damage. > I have an updated mingw-get-inst package that I haven't been > able to upload (I also wanted to add mingw-get-inst to the CVS repo, > including previous releases in the version history, but was obviously > stymied on that). It has also prevented me from committing and uploading the fix for the defect in mingw-get upgrade, which Chris reported a week or so back. > As far as "switching" to another version control system, two points: > > 1) If sourceforge doesn't support it, mingw won't use it. We have > no plans to switch to another source control hosting provider. And therein lies a potentially serious problem for us: if you read that article Chris points us to, there is a definitive suggestion that SF may pull the plug on CVS forever; they are hinting at an enforced migration to SVN, for all projects who are still using CVS. > 2) Sad as it may be, one of the primary requirements for mingw to use > a VCS other than CVS, is: do we have a port that is well-integrated > with our offerings? > > Right now, the answer is "no" -- all we have is CVS. So, where do we go from here? It's all well and good telling those who have been clamouring for alternatives to CVS to "put up or shut up", but if SF pull the plug on CVS, we need a fall back plan. In the past, I've resisted calls to migrate to SVN, not just out of inertia, or because we don't have a suitable client in our arsenal, but primarily because I do not believe it offers sufficient benefit over CVS to justify the move. I still believe this; if we are going to adopt a different SCM system, then we should be considering one of the distributed systems. Now, personally I find git to quite repulsive. However, the revulsion is mostly subjective rather than objective, (mostly due to the meaning of the word "git" itself, in British English -- a really poor choice by Linus, IMO). In spite of the perceived oddness of msys-git, it may well represent the best technical choice for us, given the potential difficulties for us in supporting hg or bzr, if SF force us to drop CVS. -- Regards, Keith. |
From: Earnie <ea...@us...> - 2011-01-31 13:03:43
|
Keith Marshall wrote: > > Now, personally I find git to quite repulsive. However, the revulsion > is mostly subjective rather than objective, (mostly due to the meaning > of the word "git" itself, in British English -- a really poor choice by > Linus, IMO). In spite of the perceived oddness of msys-git, it may well > represent the best technical choice for us, given the potential > difficulties for us in supporting hg or bzr, if SF force us to drop CVS. > For what we do git is a bit overboard but if we change I suggest that is what we move to. Has anyone tried to build git? I downloaded the msys-git version and moved the relevant git pieces to my /bin directory without affecting the operation. I believe though the current git in msys-git is not a MSYS dependent application, it just needs some of the tools provided by MSYS. Another option to consider is using the server at www.mingw.org to host a VCS repository instead of using SF. The benefit would be that we don't have to depend on SF to provide the function for us. Earnie |
From: Erwin W. <wat...@xs...> - 2011-01-31 12:33:33
|
On 01/30/2011 09:46 PM, Charles Wilson wrote: > As far as "switching" to another version control system, two points: > > > 2) Sad as it may be, one of the primary requirements for mingw to use a > VCS other than CVS, is: do we have a port that is well-integrated with > our offerings? Why does it have to be integrated in MinGW/MSYS? It's easy to type your svn/git commands in a parallel Cygwin window. Erwin |
From: Earnie <ea...@us...> - 2011-01-31 12:56:35
|
Erwin Waterlander wrote: > On 01/30/2011 09:46 PM, Charles Wilson wrote: >> As far as "switching" to another version control system, two points: >> >> >> 2) Sad as it may be, one of the primary requirements for mingw to use a >> VCS other than CVS, is: do we have a port that is well-integrated with >> our offerings? > > Why does it have to be integrated in MinGW/MSYS? It's easy to type your > svn/git commands in a parallel Cygwin window. > Because many who install MSYS do not want to also install Cygwin. We need to be self sufficient. Earnie |
From: Erwin W. <wat...@xs...> - 2011-01-31 13:49:05
|
On 01/31/2011 01:56 PM, Earnie wrote: > >> Why does it have to be integrated in MinGW/MSYS? It's easy to type your >> svn/git commands in a parallel Cygwin window. >> > Because many who install MSYS do not want to also install Cygwin. We > need to be self sufficient. > So it only requires a small change of mind. Erwin |
From: Earnie <ea...@us...> - 2011-02-01 13:30:20
|
Erwin Waterlander wrote: > On 01/31/2011 01:56 PM, Earnie wrote: >> >>> Why does it have to be integrated in MinGW/MSYS? It's easy to type your >>> svn/git commands in a parallel Cygwin window. >>> >> Because many who install MSYS do not want to also install Cygwin. We >> need to be self sufficient. >> > > So it only requires a small change of mind. Whose mind? Your's? Cause it sure isn't going to be mine. Earnie |
From: Luke K. C. L. <lk...@lk...> - 2011-01-31 14:07:19
|
On Sun, Jan 30, 2011 at 8:46 PM, Charles Wilson <cwi...@us...> wrote: > So...for all the clamoring...let me put it this way: put up or shut up. git-win32. > For instance, bzr requires a port of python (which has its own massive > list of dependencies). been there, done that. can confirm: it's a big task, made all the larger by unbelievable resistance from the python software foundation core developers. it's a big task made all the more awkward by bash under mingw32 being about 0.7 to 1.5 *seconds* to fork a new shell. the configure script therefore runs like treacle, taking some 10-15 minutes to complete. i ran MSYS under Wine and it was even worse, taking some 30-40 minutes to complete. i therefore cut out massive sections and pre-prepared an nt_config.h in place of the auto-generated config.h: that got the configure step down to an (only slightly insane) 10 minutes, meaning that under "native" win32 it would be about 3-4 minutes. but - yeah, roumen petrov is continuing to maintain, against the tide, python 2.7 and 3.1 patches to allow python to be compiled for the mingw32 platform, as he has been for almost 3-4 years now. you _can_ cut down python somewhat (but not that much cutting is actually needed), the dependencies _are_ out there (and aren't that many - you can get away with about 6 to 8, many of which already are packaged), i _have_ successfully confirmed that python works under mingw32 etc. etc. bzip lib, a couple of strange ones (had to modify one of the gnu packages to add an implementation of flock)... damnit this was 18 months ago so my memory of what i did is getting rusty. apologies. > git requires, among many other things, a newer > port of perl than our current 5.6.x (perl-5.8.x is actually on my TODO > list, but I haven't accumulated enough 'tuits yet, even piggy-backing on > msys-git's existing work there. git-win32. > And let's not even think about > perl-5.10.x...IMO that's an msys-2.0 project.) git-win32. i _did_ say, right at the beginning, in the very first reply, that the git-win32 team have already done all the work, and created a stand-alone ready-to-use package, based ironically on mingw32. l. |
From: Luke K. C. L. <lk...@lk...> - 2011-01-31 14:12:24
|
On Mon, Jan 31, 2011 at 1:06 PM, Earnie <ea...@us...> wrote: > We'll end up providing just the git client so that anyone working in a > Windows environment can just use that. Unlike msys-git it will only > contain the necessary git client tools to add instead of a complete MSYS > environment. *scratches head* ohh. yeah. i forgot. yeah, git is written in c, and the other stuff is there for the extensions, server-side stuff and for other protocols such as git+ssh. even on debian they split it into multiple packages (git-core as the base). so yeah good strategy earnie. stick to built-in stuff (http protocol) and it'd be far, far less code needed. actually, much better than svn which needs libapr and libaprutil abstraction layers (from what i recall). Depends: libsvn1 (= 1.5.1dfsg1-5), libapr1, libc6 (>= 2.7-1), libsasl2-2 ok just libapr not libaprutil. wtf? sasl?? :) l. |
From: Earnie <ea...@us...> - 2011-02-01 13:43:31
|
Luke Kenneth Casson Leighton wrote: > On Mon, Jan 31, 2011 at 1:06 PM, Earnie <ea...@us...> wrote: > >> We'll end up providing just the git client so that anyone working in a >> Windows environment can just use that. Unlike msys-git it will only >> contain the necessary git client tools to add instead of a complete MSYS >> environment. > > *scratches head* ohh. yeah. i forgot. yeah, git is written in c, > and the other stuff is there for the extensions, server-side stuff and > for other protocols such as git+ssh. even on debian they split it > into multiple packages (git-core as the base). > So, are you willing to try your hand at creating an MSYS dependent package of the client tools? It would run faster within MSYS if it is dependent on the MSYS runtime because the path translations do not take place and the MSYS dll will already be loaded in memory at the time of the fork. You can read the specifics of creating a MSYS package at www.mingw.org/wiki/HOWTO under the MSYS HOWTOS header. Earnie |
From: Luke K. C. L. <lk...@lk...> - 2011-01-31 15:11:20
|
On Mon, Jan 31, 2011 at 2:18 PM, John E. / TDM <td...@td...> wrote: > On 1/31/2011 6:06 AM, Earnie wrote: >> John E. / TDM wrote: >>> As a complement to Luke's suggestion of using Git, I'd like to strongly >>> recommend Mercurial (hg). I will not and cannot say that it is >> NO! > > Your project, your rules. I'm sorry you find hg so abhorrent. john, i can tell you, definitely, it's not "rules", it's sheer practicality. python really is a bitch to get working under mingw32 - it's why muggins (me) tackled it. compiling git - actually taking msys-git and cutting it back drastically (no point reinventing work) - is a walk in the park by comparison. so it's nothing to do with hg, great as it may be, but having something like python being _that_ low-level in the dependencies would be a complete nightmare. l. |