Menu
▾
▴
gnuplot-beta
|
From: <es...@th...> - 2014-02-21 14:34:11
|
Something unfortunate is going on with my list subscription. Mailman tells me I'm subscribed, but I'm not seeing list mail; I'm having to read this thread through the archive interface. Ethan A Merritt writes: >Can you summarize in what ways your conversion would be different >from the automated cvs->git conversion service offered by SourceForge >(which so far the project has declined to use)? Before going into the details, I should make clear that I did not specify a target VCS in my offer because I can up-convert to either git or hg very easily - gnuplot can choose either. I retain a lingering preference for hg myself, but I advise going with git anyway - it presents the lowest entry to the largest number of potential contributors. I don't know what SF uses for its conversions; the service is a recent invention and Google isn't turning up documentation on it for me. There aren't many possibilities - maintained and documented tools for this purpose are thin on the ground. I fear they are probably using cvsps called by git-cvsimport, because that is what the git suite ships. Unfortunately, cvsps is so irreparably broken that I, acting as its last maintainer, end-of-lifed it a couple of months ago. Mojca Miklavec can confirm what a mess it is; she tried doing a test conversion and got horrible results. The git devs don't realize how bad the situation is. Through an odd set of circumstances, last year I wound up as the maintainer of both cvsps and Keith Packard's parsecvs code, which I rewrote significantly and renamed cvs-fast-export. After EOLing cvsps, I shifted my effort to cvs-fast-import, which is what Mojca Miklavec has been doing her most recent test conversions with. cvsps and cvs-fast-export are two of only three possibilities SF might be using. The third is cvs2git, which has some problems of its own that I am trying to help its maintainer fix. All three of these tools, by themselves, are too weak to produce a really high-quality conversion. The things they don't do include: 1. Lifting CVS version references in comments into a form that will still be usable in git or hg. 2. Complete coalescence of CVS change cliques into changesets. They often only do this partially, one reason being that the default merge window is set too low. 3. Mapping of .cvsignores to .gitignores. My newer versions of cvs-fast-export do this but neither cvs2git nor the cvsps version in the git suite does. 4. Cleaning up conversion artifacts and junk branches. I can't be more specific about this in advance because each CVS repo tends to have its own unique set of strange malformations. Fortunately, gnuplot's history seems exceptionally clean and I expect relatively few problems. 5. (Optional) Canonicalizing change comments to git summary + continuation form. Completing these tasks requires human judgment. The only way to get a really good conversion is to follow up application of a batch converter with skilled hand-editing, and reposurgeon is the only existing tool for that. It's an interpreter for a domain-specific language built around repository-editing primitives. (As previously noted, I am currently in the process of lifting Emacs's history from bzr to git with reposurgeon. That is an exceptionally large and messy conversion, far more complex than I expect gnuplot's to be.) I have done about half a dozen large conversions before; the most recent completed one was GNU troff. You can read about my procedures in the DVCS Migration HOWTO: http://www.catb.org/esr/dvcs-migration-guide.html Ideally, I team with an inside developer who knows the project's history and idiosyncracies and is highly motivated to make the conversion succeed. For this project, Mojca Miklavec has claimed that role - she has already supplied one of the key pieces of metadata, a map from developers' CVS usernames to full names and email addresses. If the project elects to go ahead, our work product would be a lift script - that is, a file containing surgical instructions to reposurgeon - which would be available for review before the actual conversion day. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491 |
|
From: Achim G. <Str...@ne...> - 2014-02-21 16:50:02
|
Eric S. Raymond writes: > Something unfortunate is going on with my list subscription. Mailman > tells me I'm subscribed, but I'm not seeing list mail; I'm having > to read this thread through the archive interface. You can switch off (and back on) delivery to your address seperately on the subscription management page. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada |
|
From: Eric S. R. <es...@th...> - 2014-02-24 14:31:00
|
Clark Gaylord <cla...@fa...>: > I'm not sure what is up with your subscription posting, but I very > strongly concur with the substance of your suggestion regarding the > repository and converting to a distributed source management system. I've started getting list mail, so whatever glitch was involved has subsided. > My personal preference is hg, but I agree that there are lots of git > users out there, especially due to Linux kernel development. In my > experience, it is fairly easy for cvs/svn users to convert to hg; I > suspect it is similar for git. The learning barrier is a little higher for git because its UI is rather spiky, but - broadly - yes. Neither is very difficult, and anything not-CVS is a sufficiently large improvement over CVS that the transition costs get paid back in decreased hassle very quickly. > I have a few dozen developers in my > group and elsewhere in my organization who have largely converted to hg > and git from CVS and SVN over the last few years, and reactions have > ranged from "doesn't negatively impact me" to enthusiastic adopters. I > think it is fair to say that on average the more sophisticated the > user, the more enthusiastic the reaction has been. That matches my experience. > Thanks for the suggestion. Please feel free to let me know if you have > any further data on your ability to post and I'll try to track it down. As I said above, no longer a problem. I'm trying to get the Emacs conversion squared away now. I'm not in a big hurry to do gnuplot, but I do urge your project leadership to address three questions: (1) Are you ready to move away from CVS? I hope so...it's pretty broken, and it's slowly dying; there hasn't been a maintainance release since 2008. Projects that stick with CVS face increasing difficulties in attracting new devs. (2) Where do you want to land? As bzr is now moribund, the realistic alternatives are Subversion, git, and hg. But I mention Subversion only for completeness; the advantages of distributed VCS are huge and if you're going to incur the transition costs of moving away from CVS either git or hg would have a much higher functional payoff. (3) When do you want to do it? The real question here is whether you think you need to wait until after your next point release. My impression from the list traffic is that your development tempo is relatively slow, so the minor distruption from the switchover should be tolerable at any time. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> |
|
From: Daniel J S. <dan...@ie...> - 2014-02-24 15:22:56
|
On 02/24/2014 08:30 AM, Eric S. Raymond wrote: > (2) Where do you want to land? > > As bzr is now moribund, the realistic alternatives are Subversion, > git, and hg. But I mention Subversion only for completeness; the > advantages of distributed VCS are huge and if you're going to incur > the transition costs of moving away from CVS either git or hg would > have a much higher functional payoff. A few days ago I was thinking that perhaps a conversion to both git/hg could be done and for a month the developers try to keep cvs/git/hg in sync and at the end of the month decide which is preferred. The summer months are usually when there is most free time for that sort of thing. Dan |
|
From: Eric S. R. <es...@th...> - 2014-02-24 15:29:16
|
Daniel J Sebald <dan...@ie...>: > A few days ago I was thinking that perhaps a conversion to both > git/hg could be done and for a month the developers try to keep > cvs/git/hg in sync and at the end of the month decide which is > preferred. The summer months are usually when there is most free > time for that sort of thing. I advise against trying to maintain two repositories at once. That way lies only pain. Fortunately the git suite recently added the capability to use hg as a client to a remote git repository. So the repository conversion would only have to be done once. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> |
|
From: Tait <gnu...@t4...> - 2014-02-24 20:14:02
|
"Eric S. Raymond" <es...@th...> said (on 2014/02/24): > (2) Where do you want to land? > > As bzr is now moribund, the realistic alternatives are Subversion, > git, and hg. But I mention Subversion only for completeness; the > advantages of distributed VCS are huge and if you're going to incur > the transition costs of moving away from CVS either git or hg would > have a much higher functional payoff. I'd not heard Bazaar was moribund... they seem to be still making new releases? (... However, SourceForge doesn't appear to support bzr, so it's probably moot to this discussion.) Has anyone studied/published how many projects have switched from Hg to git, and vice-versa? From my personal anecdotal experience, I know of a couple that have hg->git (mostly due to difficulties with branching), but none that have git->hg. Support for all three (#bzr, #mercurial, #git) can be had on irc.freenode.net. #Git is by far the largest channel of those (for whatever that's worth) and seems to have the largest list of projects using it, so momentum seems to favor git there. Hg doesn't have the concept of an index (or stage, depending on the age of the documentation), so it will be more similar to CVS/SVN in work flow. |
|
From: Mojca M. <moj...@gm...> - 2014-02-24 21:51:31
|
On Mon, Feb 24, 2014 at 9:13 PM, Tait wrote: > "Eric S. Raymond" said (on 2014/02/24): >> (2) Where do you want to land? >> >> As bzr is now moribund, the realistic alternatives are Subversion, >> git, and hg. But I mention Subversion only for completeness; the >> advantages of distributed VCS are huge and if you're going to incur >> the transition costs of moving away from CVS either git or hg would >> have a much higher functional payoff. > > I'd not heard Bazaar was moribund... they seem to be still making new > releases? (... However, SourceForge doesn't appear to support bzr, so > it's probably moot to this discussion.) While they might make new releases, the popularity lags way behind. (And consequently there are way less tools and services supporting it.) Also, Bazaar is not the only alternative, but all other tools have even lower popularity and adoption. So yes, discussing anything but those three doesn't seem worth it. > Has anyone studied/published how many projects have switched from Hg > to git, and vice-versa? That's difficult enough, but you can feed the search engine with "convert git mercurial" and figure out that just about every hit explains how to convert from mercurial to git. The first hit about conversion from git to mercurial was from the time when bitbucket was the only provider of free hosting of private repositories and only supported mercurial. > From my personal anecdotal experience, I know > of a couple that have hg->git (mostly due to difficulties with > branching), but none that have git->hg. ... which confirms the above observation. > Support for all three (#bzr, #mercurial, #git) can be had on > irc.freenode.net. #Git is by far the largest channel of those (for > whatever that's worth) The "mean" explanation would be that git must be so difficult to use that its users need most support ;) > and seems to have the largest list of projects > using it, so momentum seems to favor git there. Here are some numbers, showing about three times more git users than those of mercurial: http://zeroturnaround.com/rebellabs/devprod-report-revisited-version-control-systems-in-2013/ http://qa.debian.org/popcon-graph.php?packages=subversion+git+mercurial+bazaar&show_installed=on&show_vote=on&want_legend=on&want_ticks=on&from_date&to_date&hlght_date&date_fmt=%25Y-%25m http://wiki.bazaar.canonical.com/BzrPopularity http://bazaarvcs.wordpress.com/2010/02/15/bazaar-adoption-growing-strongly/ (they stopped writing the blog in 2012) http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs-which-to-recommend latest counting of tags on stackoverflow – git: 37547, mercurial: 5878 (In the spirit of the same argument as above about BitBucket driving the git->hg conversion, I would dare to claim that GitHub contributed a lot towards the high popularity of git.) Anyway, whatever tool (out of the three) would be chosen ... it would be a lot better than CVS. Mojca |
|
From: Clark G. <cla...@fa...> - 2014-02-24 13:33:42
|
Hello Eric -- I'm not sure what is up with your subscription posting, but I very strongly concur with the substance of your suggestion regarding the repository and converting to a distributed source management system. My personal preference is hg, but I agree that there are lots of git users out there, especially due to Linux kernel development. In my experience, it is fairly easy for cvs/svn users to convert to hg; I suspect it is similar for git. I have a few dozen developers in my group and elsewhere in my organization who have largely converted to hg and git from CVS and SVN over the last few years, and reactions have ranged from "doesn't negatively impact me" to enthusiastic adopters. I think it is fair to say that on average the more sophisticated the user, the more enthusiastic the reaction has been. Thanks for the suggestion. Please feel free to let me know if you have any further data on your ability to post and I'll try to track it down. Regards Clark -- Clark Gaylord gnuplot sysadmin Blacksburg VA cla...@gm... On Fri, 21 Feb 2014 09:34:04 -0500 (EST), Eric S. Raymond wrote: > Something unfortunate is going on with my list subscription. Mailman > tells me I'm subscribed, but I'm not seeing list mail; I'm having > to read this thread through the archive interface. > > Ethan A Merritt writes: >> Can you summarize in what ways your conversion would be different >> from the automated cvs->git conversion service offered by SourceForge >> (which so far the project has declined to use)? > > Before going into the details, I should make clear that I did not > specify a target VCS in my offer because I can up-convert to either > git or hg very easily - gnuplot can choose either. I retain a > lingering preference for hg myself, but I advise going with git > anyway - it presents the lowest entry to the largest number of > potential contributors. > > I don't know what SF uses for its conversions; the service is a recent > invention and Google isn't turning up documentation on it for me. > There aren't many possibilities - maintained and documented tools for > this purpose are thin on the ground. I fear they are probably using > cvsps called by git-cvsimport, because that is what the git suite > ships. > > Unfortunately, cvsps is so irreparably broken that I, acting as its last > maintainer, end-of-lifed it a couple of months ago. Mojca Miklavec can > confirm what a mess it is; she tried doing a test conversion and got > horrible results. The git devs don't realize how bad the situation > is. > > Through an odd set of circumstances, last year I wound up as the > maintainer of both cvsps and Keith Packard's parsecvs code, which I > rewrote significantly and renamed cvs-fast-export. After EOLing > cvsps, I shifted my effort to cvs-fast-import, which is what Mojca > Miklavec has been doing her most recent test conversions with. > > cvsps and cvs-fast-export are two of only three possibilities SF > might be using. The third is cvs2git, which has some problems of > its own that I am trying to help its maintainer fix. > > All three of these tools, by themselves, are too weak to produce > a really high-quality conversion. The things they don't do include: > > 1. Lifting CVS version references in comments into a form that > will still be usable in git or hg. > > 2. Complete coalescence of CVS change cliques into changesets. They > often only do this partially, one reason being that the default > merge window is set too low. > > 3. Mapping of .cvsignores to .gitignores. My newer versions of > cvs-fast-export do this but neither cvs2git nor the cvsps version in > the git suite does. > > 4. Cleaning up conversion artifacts and junk branches. I can't be > more specific about this in advance because each CVS repo tends to > have its own unique set of strange malformations. Fortunately, > gnuplot's history seems exceptionally clean and I expect relatively > few problems. > > 5. (Optional) Canonicalizing change comments to git summary + > continuation form. > > Completing these tasks requires human judgment. The only way to get a > really good conversion is to follow up application of a batch > converter with skilled hand-editing, and reposurgeon is the only > existing tool for that. It's an interpreter for a domain-specific > language built around repository-editing primitives. > > (As previously noted, I am currently in the process of lifting Emacs's > history from bzr to git with reposurgeon. That is an exceptionally > large and messy conversion, far more complex than I expect gnuplot's > to be.) > > I have done about half a dozen large conversions before; the most > recent completed one was GNU troff. You can read about my procedures > in the DVCS Migration HOWTO: > > http://www.catb.org/esr/dvcs-migration-guide.html > > Ideally, I team with an inside developer who knows the project's > history and idiosyncracies and is highly motivated to make the > conversion succeed. For this project, Mojca Miklavec has claimed that > role - she has already supplied one of the key pieces of metadata, a > map from developers' CVS usernames to full names and email addresses. > > If the project elects to go ahead, our work product would be a lift > script - that is, a file containing surgical instructions to > reposurgeon - which would be available for review before the actual > conversion day. > -- > <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> > > Where rights secured by the Constitution are involved, there can be no > rule making or legislation which would abrogate them. > -- Miranda vs. Arizona, 384 US 436 p. 491 > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
