[slime-devel] Mercurial
What do people think of switching from CVS to Mercurial[*] ? Helmut. [*] http://www.selenic.com/mercurial/
On Tue, Mar 4, 2008 at 1:21 PM, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
Why not GIT? SBCL switched from CVS to git with a success. Nikodem S. wrote very good tutorial. -- Best regards, Rafal Strzalinski (nabla) http://nablaone.net
"Rafał Strzaliński" <nablaone@gmail.com> writes:
On Tue, Mar 4, 2008 at 1:21 PM, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
Why not GIT? SBCL switched from CVS to git with a success. Nikodem S. wrote very good tutorial.
For the record, SBCL did no such thing. (I have never used Mercurial, so cannot comment on the original question). Best, Christophe
* Rafaâ Strzaliäski [2008-03-04 13:46+0100] writes:
On Tue, Mar 4, 2008 at 1:21 PM, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
Why not GIT? SBCL switched from CVS to git with a success. Nikodem S. wrote very good tutorial.
The big three VCSes currently seem to be Git, Mercurial and Bazaar. Git is the most popular, most powerful, but also the most complicated. (It could be argued, that Nikodemus' tuturial is an indicator that git usuage isn't entirely obvious.) Some people say that it doesn't run so well on Windows, because it's written in C+sh+perl. The other two are written in Python and claim that the platform issues are handled (mostly) by Python. I think the "runs on Windows" thing was the main reason why Mozilla uses Mercurial and not Git. Bazaar (bzr) is arguably easier to use, primarily because it has consistent options for the various commands and the commands have usually similar counter parts in CVS and SVN. My main complaint about bzr is that the "bzr log -l 10" command takes 2 seconds on the SLIME repo. The other thing that I don't like much is the handling of "short lived branches". With bzr you must create at separate directory for each branch, with the others you can switch the branch in the same directory. Mercurial (hg) is IMHO as easy to use as bzr---the commands are similar to CVS---but is the more mature and scales better. It doesn't support branches as well as Git does, but I feel more confident using Mercurial. There are also some niceties bundled with the main distro, like the local webserver and the glog command. All this is also available for Git and bzr but hg is a nice, relatively small, package. Here are the sizes for the repos on my disk: $ du -h -s slime-bzr/.bzr/ slime-git/.git slime-hg/trunk/.hg/ 8.1M slime-bzr/.bzr/ 7.1M slime-git/.git 3.9M slime-hg/trunk/.hg/ This doesn't necessarily mean that Mercurial is more space efficient in the long run. Those are just repos converted from CVS and I messed a bit around with each of them. I found this quote somewhere: On OpenSolaris plans for a new VCS <ddaa> I think they realized there are two kinds of dscms... <ddaa> the obsolete ones and the experimental ones That's also my impression. All three are pretty close to each other, but I think Mercurial is currently the best choice. Helmut.
On Tue, Mar 04, 2008 at 02:48:46PM +0100, Helmut Eller wrote:
* Rafaâ Strzaliäski [2008-03-04 13:46+0100] writes:
On Tue, Mar 4, 2008 at 1:21 PM, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
Why not GIT? SBCL switched from CVS to git with a success. Nikodem S. wrote very good tutorial.
The big three VCSes currently seem to be Git, Mercurial and Bazaar.
I certainly don't vote here, but I thought I'd bring one more data point. I have used Monotone in the past, and then switched some of my repositories to Git, some to Mercurial. I found Git to be somewhat complex as others said. Mercurial was fast and nice *until* I had to do non-trivial things like cloning a large repository or sending several isolated deltas from the past via email. I'm going back to Monotone. It may be somewhat slower, but it is *very* robust[0], is being actively developed, has very good documentation[1] and no complex dependencies. There is also support for visualizing the commit graph, among other interesting features. I have never used bzr, so I can't compare it to Monotone. J. [0] Besides heavy black-box tests, invariants are checked all over the code, and there are tools for checking the integrity of a repository. [1] Disclaimer: I wrote a section of the manual (the tutorial on packets).
* Jeronimo Pellegrini [2008-03-04 17:48+0100] writes:
On Tue, Mar 04, 2008 at 02:48:46PM +0100, Helmut Eller wrote:
* Rafaâ Strzaliäski [2008-03-04 13:46+0100] writes:
On Tue, Mar 4, 2008 at 1:21 PM, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
Why not GIT? SBCL switched from CVS to git with a success. Nikodem S. wrote very good tutorial.
The big three VCSes currently seem to be Git, Mercurial and Bazaar.
I certainly don't vote here, but I thought I'd bring one more data point.
I have used Monotone in the past, and then switched some of my repositories to Git, some to Mercurial. I found Git to be somewhat complex as others said. Mercurial was fast and nice *until* I had to do non-trivial things like cloning a large repository or sending several isolated deltas from the past via email.
I'm going back to Monotone. It may be somewhat slower, but it is *very* robust[0], is being actively developed, has very good documentation[1] and no complex dependencies. There is also support for visualizing the commit graph, among other interesting features.
I never use Monotone. SLIME is such a small project and I would assume that we only need the basic features; about the those things that we used CVS for. It would be rather disappointing if Mercurial wouldn't fulfil those moderate needs. Helmut.
On Tue, Mar 04, 2008 at 02:48:46PM +0100, Helmut Eller wrote:
Here are the sizes for the repos on my disk: $ du -h -s slime-bzr/.bzr/ slime-git/.git slime-hg/trunk/.hg/ 8.1M slime-bzr/.bzr/ 7.1M slime-git/.git 3.9M slime-hg/trunk/.hg/
I'm not trying to influence things here one way or another (I personally prefer Git, but then again I pretty much don't do Slime work anymore either), but a simple one-time archival repack (git repack -adf --window=250 --depth=250) improves things for Git quite a lot: :; du -h -s slime/.git 3.1M slime/.git I know repacking is often brought up as a downside of Git, but after using it for close to a year now in a environment with a large (proprietary) repository (~420MB packed, 40,000+ files, ten year history), it just hasn't been an issue. It's really nice being able to make a time/space tradeoff where you prefer. (And yes, Git is seemingly impossibly fast on this repository. It's about an order of magnitude slower on Windows, but so is everything else; Windows's stat call is just slow.) -bcd
* Brian Downing [2008-03-04 18:08+0100] writes:
On Tue, Mar 04, 2008 at 02:48:46PM +0100, Helmut Eller wrote:
Here are the sizes for the repos on my disk: $ du -h -s slime-bzr/.bzr/ slime-git/.git slime-hg/trunk/.hg/ 8.1M slime-bzr/.bzr/ 7.1M slime-git/.git 3.9M slime-hg/trunk/.hg/
I'm not trying to influence things here one way or another (I personally prefer Git, but then again I pretty much don't do Slime work anymore either), but a simple one-time archival repack (git repack -adf --window=250 --depth=250) improves things for Git quite a lot:
:; du -h -s slime/.git 3.1M slime/.git
I know repacking is often brought up as a downside of Git, but after using it for close to a year now in a environment with a large (proprietary) repository (~420MB packed, 40,000+ files, ten year history), it just hasn't been an issue. It's really nice being able to make a time/space tradeoff where you prefer.
I think I know why mine is so big. I did git-gc and git-repack but I did also git-cvsimport several times and probably on different machines. Silly me. That probably duplicated some/most changesets. I guess everybody can afford 5-10Mb diskspace (+ 3Mb for the working tree). This sizes is primarily interesting for the first checkout, which will be _slower_ than a checkout with CVS. Later updates will then hopefully be much more efficient. Helmut.
Some folks have mentioned that they've found it difficult to started with git. I found http://video.google.com/videoplay?docid=-3999952944619245780 very helpful.
I certainly don't have voting rights here, but you may want to have a look at git. On Tue, Mar 04, 2008 at 01:21:40PM +0100, Helmut Eller wrote:
What do people think of switching from CVS to Mercurial[*] ?
Helmut.
[*] http://www.selenic.com/mercurial/
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
* Nikodemus Siivola [2008-03-04 16:07+0100] writes:
On 3/4/08, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
I have no experience with it, but no objections either. The only question I have is the status of Mercurial support on common-lisp.net.
It's currently not installed. But I hope the cl.netters don't mind to install it. I did a local install there and also installed the cgi script (well, server-side include) under http://common-lisp.net/project/slime/hgweb.shtml. I think it doesn't need any other upgrades. I think hg has some hooks to send emails after a commit, so we would send that to the slime-cvs mailing list. I haven't tried it, though. The script for the daily changelog summary would probably need some adjustments. It would be nice to have a CVS mirror of the Mercurial repository (so that non-committers wouldn't notice the switch) but I couldn't find an simple solution to that. Helmut.
Speaking with my common-lisp.net admin hat on, I'm happy to install either git, hg or both. In fact, they'd probably be good to have in any case. With my usual hat on (the one with funny ears), I'm wondering "why not darcs?". Did darcs lose out in the DVCS "wars" because they haven't managed to fix the "exponential time" bug? thanks, On Mar 4, 2008, at 10:26 AM, Helmut Eller wrote:
* Nikodemus Siivola [2008-03-04 16:07+0100] writes:
On 3/4/08, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
I have no experience with it, but no objections either. The only question I have is the status of Mercurial support on common- lisp.net.
It's currently not installed. But I hope the cl.netters don't mind to install it. I did a local install there and also installed the cgi script (well, server-side include) under http://common-lisp.net/project/slime/hgweb.shtml. I think it doesn't need any other upgrades.
I think hg has some hooks to send emails after a commit, so we would send that to the slime-cvs mailing list. I haven't tried it, though. The script for the daily changelog summary would probably need some adjustments.
It would be nice to have a CVS mirror of the Mercurial repository (so that non-committers wouldn't notice the switch) but I couldn't find an simple solution to that.
Helmut.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
-- Gary Warren King, metabang.com Cell: (413) 559 8738 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
* Gary King [2008-03-04 17:18+0100] writes:
Speaking with my common-lisp.net admin hat on, I'm happy to install either git, hg or both. In fact, they'd probably be good to have in any case.
With my usual hat on (the one with funny ears), I'm wondering "why not darcs?". Did darcs lose out in the DVCS "wars" because they haven't managed to fix the "exponential time" bug?
I think the more serious Darcs' problem is the dependence on Haskell/GHC, which is a much more exotic requirement than Python. Helmut.
Gary King <gwking@metabang.com> wrote:
With my usual hat on (the one with funny ears), I'm wondering "why not darcs?". Did darcs lose out in the DVCS "wars" because they haven't managed to fix the "exponential time" bug?
Nice hat :-) I personally continue using Darcs for my personal stuff, because I like it, especially, the interactive behavior. However, no, I don't think it scales very well yet. -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier@xemacs.org
* Gary King <gwking@metabang.com>:
With my usual hat on (the one with funny ears), I'm wondering "why not darcs?". Did darcs lose out in the DVCS "wars" because they haven't managed to fix the "exponential time" bug?
Didn't they fix this in Darcs 2.0 (still pre-release)? Anyway, I've tried (briefly) Git, Mercurial, Bazaar, etc, and I think Darcs has easily the most intuitive interface of any of them. -- johs
Mercurial can mimic Darcs' user interface with the record extension: http://www.selenic.com/mercurial/wiki/index.cgi/RecordExtension On 3/4/08, Johannes Groedem <johs@netfonds.no> wrote:
Didn't they fix this in Darcs 2.0 (still pre-release)? Anyway, I've tried (briefly) Git, Mercurial, Bazaar, etc, and I think Darcs has easily the most intuitive interface of any of them.
-- Juan M. Bello Rivas
On Tue, Mar 04, 2008 at 07:24:33PM +0100, Juan M. Bello Rivas wrote:
Mercurial can mimic Darcs' user interface with the record extension:
Git also has 'add -i' for interactive add. Also, be careful not to read too many out-of-date things about git not working under Windows. David
On Tue, Mar 04, 2008 at 11:18:17AM -0500, Gary King wrote:
With my usual hat on (the one with funny ears), I'm wondering "why not darcs?". Did darcs lose out in the DVCS "wars" because they haven't managed to fix the "exponential time" bug?
As far as I know it can explode into exponential time, with generally unpleasant actions required to fix it, because of doing actions (repeated merges) that are common and something that you really want to do in a distributed version control system. That's a pretty critical problem, IMHO. Maybe most projects don't get there, but I managed to wedge Darcs almost immediately when trying to use it on SBCL. I also don't like the fact that Darcs doesn't really model history, which I consider to be a very important part of a SCM. In almost all other systems, there a unique identifier, usually 40 characters or less, that can uniquely identify each and every revision, globally. In darcs, you either have to have a long patchset file, or you have to tag (how CVS!) to identify a version. I like the patch algebra idea, but in practical terms I feel I can achieve almost all the same benefits with Git's rebasing tools. (And in fact sometimes more benefit; I often want to remove or add a patch in a way that isn't "clean" in Darcs' view of the world, so I would have to go to extra effort to do it in Darcs as well.) -bcd
bdowning@lavos.net (Brian Downing) writes:
In almost all other systems, there a unique identifier, usually 40 characters or less, that can uniquely identify each and every revision, globally. In darcs, you either have to have a long patchset file, or you have to tag (how CVS!) to identify a version.
Do you mean a unique identifier for each patch? In darcs you can use the hash for a patch darcs annotate --summary --match \ 'hash 20040403105958-53a90-c719567e92c3b0ab9eddd5290b705712b8b918ef' Use the --xml-output option to find the hash. It 61 characters though. Cheers, Chris Dean
On 3/4/08, Chris Dean <ctdean@sokitomi.com> wrote:
Do you mean a unique identifier for each patch? In darcs you can use the hash for a patch
darcs annotate --summary --match \ 'hash 20040403105958-53a90-c719567e92c3b0ab9eddd5290b705712b8b918ef'
Use the --xml-output option to find the hash. It 61 characters though.
I don't know what Brian meant, but one of the things I miss in Darcs are global tree/commit identifiers, and identifying commits with the trees they produce. Cheers, -- Nikodemus
On 3/4/08, Helmut Eller <heller@common-lisp.net> wrote:
It would be nice to have a CVS mirror of the Mercurial repository (so that non-committers wouldn't notice the switch) but I couldn't find an simple solution to that.
If all else fails, Slime could start making timeboxed releases. :) Just kidding... Cheers, -- Nikodemus
On Tue, Mar 4, 2008 at 4:26 PM, Helmut Eller <heller@common-lisp.net> wrote:
* Nikodemus Siivola [2008-03-04 16:07+0100] writes:
On 3/4/08, Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
I have no experience with it, but no objections either. The only question I have is the status of Mercurial support on common-lisp.net.
It's currently not installed. But I hope the cl.netters don't mind to install it. I did a local install there and also installed the cgi script (well, server-side include) under http://common-lisp.net/project/slime/hgweb.shtml. I think it doesn't need any other upgrades.
I think hg has some hooks to send emails after a commit, so we would send that to the slime-cvs mailing list. I haven't tried it, though. The script for the daily changelog summary would probably need some adjustments.
It would be nice to have a CVS mirror of the Mercurial repository (so that non-committers wouldn't notice the switch) but I couldn't find an simple solution to that.
Maybe there is something like http://github.com for Mercurial? There will no need to install hg on cl.net. BTW I've imported slime to git and published it here: http://github.com/nablaone/slime/ Just for test. -- Best regards, Rafal Strzalinski (nabla) http://nablaone.net
* RafaB StrzaliDski [2008-03-04 18:59+0100] writes:
On Tue, Mar 4, 2008 at 4:26 PM, Helmut Eller <heller@common-lisp.net> wrote:
It's currently not installed. But I hope the cl.netters don't mind to install it. I did a local install there and also installed the cgi script (well, server-side include) under http://common-lisp.net/project/slime/hgweb.shtml. I think it doesn't need any other upgrades.
I think hg has some hooks to send emails after a commit, so we would send that to the slime-cvs mailing list. I haven't tried it, though. The script for the daily changelog summary would probably need some adjustments.
It would be nice to have a CVS mirror of the Mercurial repository (so that non-committers wouldn't notice the switch) but I couldn't find an simple solution to that.
Maybe there is something like http://github.com for Mercurial? There will no need to install hg on cl.net.
Mabye, but I don't know that. common-lisp.net is such a nice place, I'd like to stay there.
BTW I've imported slime to git and published it here: http://github.com/nablaone/slime/ Just for test.
A disadvantage of using Mercurial would also be that it's harder to make a mirror for git/darcs/monotone/svn/wathever. Helmut.
On Tue, Mar 04, 2008 at 08:43:51PM +0100, Helmut Eller wrote:
A disadvantage of using Mercurial would also be that it's harder to make a mirror for git/darcs/monotone/svn/wathever.
I'm using a CVS->GIT mirror right now just for my own personal tracking, just to get the better history browsing and branching of git. For me at least, moving to one that doesn't have a readily available git gateway would require me to learn another system. David
On Tue, Mar 4, 2008 at 11:15 PM, David Brown <lisp@davidb.org> wrote:
On Tue, Mar 04, 2008 at 08:43:51PM +0100, Helmut Eller wrote:
A disadvantage of using Mercurial would also be that it's harder to make a mirror for git/darcs/monotone/svn/wathever.
I'm using a CVS->GIT mirror right now just for my own personal tracking, just to get the better history browsing and branching of git.
For me at least, moving to one that doesn't have a readily available git gateway would require me to learn another system.
You may try using: http://progetti.arstecnica.it/tailor/. I'm not sure about maturity, but migration between cvs -> hg worked fine few month ago. At least for me :-) -- Best regards, Rafal Strzalinski (nabla) http://nablaone.net
I don't have a strong stake whatever you guys decide, but please - pick something such that the client will work even behind proxied firewalls. (i.e., CVS has a version that supports proxies). Thanks! -- Bradford W. Miller Cognitive/Computer Scientist/Engineer Raytheon, Inc. 1847 West Main Road Portsmouth, RI 02871-1087 (401) 842-3578
* Bradford W Miller [2008-03-04 23:33+0100] writes:
I don't have a strong stake whatever you guys decide, but please - pick something such that the client will work even behind proxied firewalls. (i.e., CVS has a version that supports proxies).
Firewalls shouldn't be a problem, because all candidates work also over HTTP. Helmut.
Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
In XEmacs, we recently switched development from CVS to mercurial. The choice pretty quickly boiled down to hg or git. I think mercurial is a bit simpler to use (it has fewer commands, but extension infrastructure if needed) and much more documented. Otherwise, they're quite equivalent in functionality. I can't remember exactly the final motivations for the decision, but if anyone is interested, I can dig into the review board list's archives. -- 5th European Lisp Workshop at ECOOP 2008, July 7: http://elw.bknr.net/2008/ Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85 94276 Le Kremlin-Bicêtre, France Fax.+33 (0)1 53 14 59 22 didier@xemacs.org
* Didier Verna [2008-03-04 16:49+0100] writes:
Helmut Eller <heller@common-lisp.net> wrote:
What do people think of switching from CVS to Mercurial[*] ?
In XEmacs, we recently switched development from CVS to mercurial. The choice pretty quickly boiled down to hg or git. I think mercurial is a bit simpler to use (it has fewer commands, but extension infrastructure if needed) and much more documented. Otherwise, they're quite equivalent in functionality. I can't remember exactly the final motivations for the decision, but if anyone is interested, I can dig into the review board list's archives.
Some other big projects are also using hg. Both, git and hg should easily handle SLIME. I would prefer hg, but the main question is: should we switch at all? Helmut.
Helmut Eller wrote:
Some other big projects are also using hg. Both, git and hg should easily handle SLIME. I would prefer hg, but the main question is: should we switch at all?
No. These days it appears that cvs is becoming the least common denominator from which people mirror git or $DVCSOFWEEK. Folks who want to use a distributed version control system can set up mirroring from cvs upstream. For the rest of us it's just one less package to install on N different computers where I have SLIME checked out. In fact it'd probably be even better if actual development took place off the mirror and got pushed to CVS HEAD when it worked reliably. Before switching to the new distributed hotness of the week, ask first if the one you're choosing is going to get enough critical mass that when the next hot version control system comes out somebody's going to bother writing an importer for your now old-and-decrepit system. If that's in doubt, you've flushed the entire point of version control (maintaining history) down the drain. I personally wouldn't mind if all the cvs users out there switched to svn, but for whatever reason that doesn't seem to be happening rapidly. svn is at the point where I think it's mature enough to deploy in broad use and well adopted enough in industry that it's not going to become unmaintained any time within the next decade. -- Brian Mastenbrook brian@mastenbrook.net http://brian.mastenbrook.net/
On Tue, Mar 4, 2008 at 8:59 PM, Brian Mastenbrook <brian@mastenbrook.net> wrote:
Helmut Eller wrote:
Some other big projects are also using hg. Both, git and hg should easily handle SLIME. I would prefer hg, but the main question is: should we switch at all?
No. These days it appears that cvs is becoming the least common denominator from which people mirror git or $DVCSOFWEEK. Folks who want to use a distributed version control system can set up mirroring from cvs upstream. For the rest of us it's just one less package to install on N different computers where I have SLIME checked out. In fact it'd probably be even better if actual development took place off the mirror and got pushed to CVS HEAD when it worked reliably.
Before switching to the new distributed hotness of the week, ask first if the one you're choosing is going to get enough critical mass that when the next hot version control system comes out somebody's going to bother writing an importer for your now old-and-decrepit system. If that's in doubt, you've flushed the entire point of version control (maintaining history) down the drain.
I personally wouldn't mind if all the cvs users out there switched to svn, but for whatever reason that doesn't seem to be happening rapidly. svn is at the point where I think it's mature enough to deploy in broad use and well adopted enough in industry that it's not going to become unmaintained any time within the next decade.
-- Brian Mastenbrook brian@mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Um, as a non-maintainer, I would vote for svn (my first exposure to version control - cannot comment on others). fwiw, it has an awsome gui interface on windows (tortoise). I use the command line interface on linux, and with the cheat sheats, life is fairly easy. I like the documentation on the web site, and the mailing lists seem fairly active. Mirko
Brian Mastenbrook <brian@mastenbrook.net> writes:
Helmut Eller wrote:
Some other big projects are also using hg. Both, git and hg should easily handle SLIME. I would prefer hg, but the main question is: should we switch at all?
No. These days it appears that cvs is becoming the least common denominator from which people mirror git or $DVCSOFWEEK. Folks who want to use a distributed version control system can set up mirroring from cvs upstream. For the rest of us it's just one less package to install on N different computers where I have SLIME checked out. In fact it'd probably be even better if actual development took place off the mirror and got pushed to CVS HEAD when it worked reliably.
what he said. this is effectively today's SBCL situation, BTW, and it Seems To Work Just Fine. cheers, --m
On Wed, Mar 05, 2008 at 08:28:44AM +0200, Michael Livshin wrote:
Brian Mastenbrook <brian@mastenbrook.net> writes:
No. These days it appears that cvs is becoming the least common denominator from which people mirror git or $DVCSOFWEEK. Folks who want to use a distributed version control system can set up mirroring from cvs upstream. For the rest of us it's just one less package to install on N different computers where I have SLIME checked out. In fact it'd probably be even better if actual development took place off the mirror and got pushed to CVS HEAD when it worked reliably.
what he said. this is effectively today's SBCL situation, BTW, and it Seems To Work Just Fine.
The irony is (and I think I can say this authoritatively, having written most of one before giving up) writing a CVS importer into a changeset-DAG-based system that works correctly in all cases is /really/ hard, by far the hardest of all of the currently-popular systems. SVN is probably second, because of its losing branches-are-copies model. It's quite easy (theoretically) to migrate between any of the changeset-DAG-based systems. At least in git's case, all of the existing CVS importers have some flaw or another: * git cvsimport: Incremental, but uses cvsps, which means it is slow and makes fantastically incorrect decisions sometimes. Treats vendor branches like normal branches, which means everything gets completely mangled. * parsecvs: Fast, not incremental, sometimes misplaces tags. This is what I've wound up using for one-time imports, and I fix the tags by hand when they're wrong. * fromcvs: Fast, incremental, doesn't do tags at all. This is what I use for incremental imports. * cvs2svn/cvs2git: Not incremental, but probably the most correct of all current importers. Unfortunately, AFAIK it still makes everything look like an SVN repository (i.e. with an extra branch for each tag). * Tailor: Slow, incremental, and has made very bad decisions on me similar to the ones that git cvsimport makes. This is getting quite off topic though, sorry... -bcd
Helmut Eller wrote:
What do people think of switching from CVS to Mercurial[*] ?
Helmut.
+1! I really like Mercurial compared to git and bzr, as it was the first of this bunch whose instructions I really understood in a brief trial period. The need for git to repack archives seems to be a weird design decision (why isn't this done semi-automatically?) Anyways, I would love to see SLIME distributed officially via Mercurial. -- <Mark.Evenson@gmx.at> "[T]his is not a disentanglement from, but a progressive knotting into."
On Wed, Mar 05, 2008 at 11:52:17AM +0100, Mark Evenson wrote:
I really like Mercurial compared to git and bzr, as it was the first of this bunch whose instructions I really understood in a brief trial period. The need for git to repack archives seems to be a weird design decision (why isn't this done semi-automatically?)
It is done semi-automatically... There is a lot of "FUD" about how git used to be. FUD is probably a bit too strong, but most of the complaints I see about git aren't true in recent versions. Git is definitely harder to learn, but I personally feel that it has been worth it. I'm not sure how much it matters for something like Slime, though. David
Is there really a good reason to switch to a new version control system and what's wrong with svn anyway? Steve On Wed, Mar 5, 2008 at 9:08 AM, David Brown <lisp@davidb.org> wrote:
On Wed, Mar 05, 2008 at 11:52:17AM +0100, Mark Evenson wrote:
I really like Mercurial compared to git and bzr, as it was the first of this bunch whose instructions I really understood in a brief trial period. The need for git to repack archives seems to be a weird design decision (why isn't this done semi-automatically?)
It is done semi-automatically...
There is a lot of "FUD" about how git used to be. FUD is probably a bit too strong, but most of the complaints I see about git aren't true in recent versions.
Git is definitely harder to learn, but I personally feel that it has been worth it. I'm not sure how much it matters for something like Slime, though.
David _______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
I have worked on branches in cvs svn and perforce. I don't know so please educate me how do these other version control systems make a marked improvement in branching and distributed development? Steve On Wed, Mar 5, 2008 at 9:33 AM, David Brown <lisp@davidb.org> wrote:
On Wed, Mar 05, 2008 at 09:16:54AM -0800, Steve Morin wrote:
Is there really a good reason to switch to a new version control system and what's wrong with svn anyway?
If you don't branch, or do distributed development, not much...
David
On Wed, Mar 05, 2008 at 11:24:42AM -0800, Steve Morin wrote:
I have worked on branches in cvs svn and perforce. I don't know so please educate me how do these other version control systems make a marked improvement in branching and distributed development?
They're all broken in different ways, but it all boils down to not storing enough metadata with the branch/merges. CVS and Perforce share in that they track files individually, not directories. This breaks down when there are renames and such in one branch. SVN doesn't store merge history, so has to be told what might be a common ancestor for a merge. None of them do distributed development, they only let other developers connect remotely. Each still checks out and checks into a single repo. A distributed system allows me to create my own branches without even needing write permission on a central repo. Without using and understanding a distributed revision control system, it's hard to understand why it is so much more powerful and useful. It is really a much better way of working. We use Perforce at my work. Most of us on my team use a Perforce->git gateway to be able to do useful tracking and distributed development. David
On Wed, Mar 5, 2008 at 4:51 PM, David Brown <lisp@davidb.org> wrote:
On Wed, Mar 05, 2008 at 11:24:42AM -0800, Steve Morin wrote:
I have worked on branches in cvs svn and perforce. I don't know so please educate me how do these other version control systems make a marked improvement in branching and distributed development?
They're all broken in different ways, but it all boils down to not storing enough metadata with the branch/merges. CVS and Perforce share in that they track files individually, not directories. This breaks down when there are renames and such in one branch. SVN doesn't store merge history, so has to be told what might be a common ancestor for a merge.
I agree with you here. For just about everyone merging is always a frustrating process. Currently I am working on a project with svn where I have to merge with 3 seperate branches and trunk not fun. This I don't know much about other techniques but, here I would need the ability to make a change in one branch and apply it to the two other branches and trunk. This needs to be very flexible.
None of them do distributed development, they only let other developers connect remotely. Each still checks out and checks into a single repo. A distributed system allows me to create my own branches without even needing write permission on a central repo.
Without using and understanding a distributed revision control system, it's hard to understand why it is so much more powerful and useful. It is really a much better way of working.
I have done to a couple presentations on Mecurial but If people are working on a common project I am not sure there is a usual need to create your own branch. If I am doing work I am not sharing with others I get my own copy or setup my own repository. Otherwise I am usually commiting to the main project, and work the with project maintainer for a branch if it's a serious effort that needs that or else you for the project if you can't see eye to eye with the "establishment"
We use Perforce at my work. Most of us on my team use a Perforce->git gateway to be able to do useful tracking and distributed development.
David
On Wed, Mar 05, 2008 at 05:26:57PM -0800, Steve Morin wrote:
I have done to a couple presentations on Mecurial but If people are working on a common project I am not sure there is a usual need to create your own branch. If I am doing work I am not sharing with others I get my own copy or setup my own repository. Otherwise I am usually commiting to the main project, and work the with project maintainer for a branch if it's a serious effort that needs that or else you for the project if you can't see eye to eye with the "establishment"
I create top branches for many changes. One workflow that works well: - I create a topic branch and work on a change - I generate a patch and email it around for feedback. - I make some changes and amend the branch (which I can only do on a private branch, before I merge it in). - I might fix up earlier parts of my patch. - Once all are satisfied, I push a nice clean change through. Once email gets involved and waiting for feedback, you either work on one change at a time, and spend most of your time waiting, or you use topic branches. What seems to happen with non-distributed/lightweight-branch systems is that the history ends up filled with half-baked changes that don't really have a coherency. But, with a distributed system, you always get at least one branch, since your workspace is a branch. David
* Helmut Eller [2008-03-04 13:21+0100] writes:
What do people think of switching from CVS to Mercurial[*] ?
Currently I'm using a private Mercurial repo and from time to time commit manually to CVS. I guess, I could automate some of the commit/conversion tasks. OTOH, if more people are maintain private repos we could save some work if we all use the same system. So lets make a poll. Those people with cvs commit rights can vote. Say which system you prefer; if you don't want to switch, vote for CVS. You can cast your ballot until 2008-March-07 00:00 UTC. I vote for Mercurial. Helmut.
On 3/5/08, Helmut Eller <heller@common-lisp.net> wrote:
So lets make a poll. Those people with cvs commit rights can vote. Say which system you prefer; if you don't want to switch, vote for CVS. You can cast your ballot until 2008-March-07 00:00 UTC.
I abstain. Cheers, -- Nikodemus
* Helmut Eller [2008-03-05 13:55+0100] writes:
So lets make a poll. Those people with cvs commit rights can vote. Say which system you prefer; if you don't want to switch, vote for CVS. You can cast your ballot until 2008-March-07 00:00 UTC.
The time is over. Since nobody voted we will stay with the status quo. Helmut.
* Tobias C. Rittweiler [2008-08-08 09:51+0200] writes:
Helmut Eller <heller@common-lisp.net> writes:
What do people think of switching from CVS to Mercurial[*] ?
Helmut.
I'd like to try that out now. My threshold of annoyance with CVS has filled up.
I think that we will not do a full switch very soon. We need to make a few smaller steps. The easiest for everyone, is probably to run a local hg repository for personal use and to commit to CVS from time to time. To get started you can try my repo. Create a local copy with: hg pull -v --remotecmd=~heller/bin/hg ssh://trittweiler@common-lisp.net/~heller/slime-hg slime-hg-local I hope that I set the permissions correctly. The Mercurial homepage[1] has links to tutorials and documentation. You might skim through the hgbook[2] a bit. The book is rather wordy. For everyday use, the documentation printed with the -h option is usually enough. Unfortunately, nobody explains how to commit to CVS. In my setup I have 2 local repos: work and outgoing. In work I do my local hacking and I use outgoing before committing to CVS. outgoing is at the same time a CVS repo, i.e. I copied the CVS directory from the original CVS repo to outgoing. The usual commit cycle is: cd work hg pull ssh://heller@common-lisp.net/slime-hg # get new changes from CVS ... merge conflicts ... ..frob stuff.. hg commit hg push -r tip ../outgoing cd ../outgoing cvs update hg up cvs commit I have a script (see attachment) to automate the last few steps. To enable it, add the following to your ~/.hgrc [extensions] slimecommit = .../slimecommit.py Then you can commit multiple changes in a batch with cd outgoing; hg slimecommit . 3587 3588 3589 The numbers are revisions to commit. The first number, 3587, must be the version which is in synch with CVS, otherwise the command fails. No, this isn't pretty, but a start. Helmut. [1]http://www.selenic.com/mercurial/wiki/ [2]http://hgbook.red-bean.com/
Helmut Eller <heller@common-lisp.net> writes:
To get started you can try my repo. Create a local copy with:
hg pull -v --remotecmd=~heller/bin/hg [...]
Did you mean clone rather than pull by chance?
I hope that I set the permissions correctly.
Trying to commit stuff with CVS takes even more time at the moment as it used to be. I get the following message in my *cvs* buffer which seems to be related: Message: sh: line 1: /home/heller/bin/convert-to-hg.sh: Permission denied -T.
* Tobias C. Rittweiler [2008-08-08 16:17+0200] writes:
To get started you can try my repo. Create a local copy with:
hg pull -v --remotecmd=~heller/bin/hg [...]
Did you mean clone rather than pull by chance?
Yes.
I hope that I set the permissions correctly.
Trying to commit stuff with CVS takes even more time at the moment as it used to be. I get the following message in my *cvs* buffer which seems to be related:
Message: sh: line 1: /home/heller/bin/convert-to-hg.sh: Permission denied
Does it work now?
Helmut Eller <heller@common-lisp.net> writes:
Trying to commit stuff with CVS takes even more time at the moment as it used to be. I get the following message in my *cvs* buffer which seems to be related:
Message: sh: line 1: /home/heller/bin/convert-to-hg.sh: Permission denied
Does it work now?
Repository : :ext:trittweiler@common-lisp.net:/project/slime/cvsroot Module : slime Working dir: ~/.emacs.d/slime/ In directory .: Message: hg: unknown command 'convert' Message: Mercurial Distributed SCM Message: Message: basic commands: Message: Message: add add the specified files on the next commit Message: annotate show changeset information per file line Message: clone make a copy of an existing repository Message: commit commit the specified files or all outstanding changes Message: diff diff repository (or selected files) Message: export dump the header and diffs for one or more changesets Message: init create a new repository in the given directory Message: log show revision history of entire repository or files Message: merge merge working directory with another revision Message: parents show the parents of the working dir or revision Message: pull pull changes from the specified source Message: push push changes to the specified destination Message: remove remove the specified files on the next commit Message: revert revert files or dirs to their states as of some revision Message: serve export the repository via HTTP Message: status show changed files in the working directory Message: update update working directory Message: Message: use "hg help" for the full list of commands or "hg -v" for details
* Tobias C. Rittweiler [2008-08-08 18:15+0200] writes:
Helmut Eller <heller@common-lisp.net> writes:
Trying to commit stuff with CVS takes even more time at the moment as it used to be. I get the following message in my *cvs* buffer which seems to be related:
Message: sh: line 1: /home/heller/bin/convert-to-hg.sh: Permission denied
Does it work now?
Repository : :ext:trittweiler@common-lisp.net:/project/slime/cvsroot Module : slime Working dir: ~/.emacs.d/slime/
In directory .: Message: hg: unknown command 'convert'
OK, I removed the commit trigger. Will have to convert manually or in a cron job. Helmut.
participants (20)
-
bdowning＠lavos.net -
Bradford W Miller -
Brian Mastenbrook -
Chris Dean -
Christophe Rhodes -
David Brown -
David J. Neu -
Didier Verna -
Gary King -
Helmut Eller -
Jeronimo Pellegrini -
Johannes Groedem -
Juan M. Bello Rivas -
Mark Evenson -
Michael Livshin -
Mirko Vukovic -
Nikodemus Siivola -
Rafał Strzaliński -
Steve Morin -
Tobias C. Rittweiler