[slime-devel] cvs committed darcs changes
dear list, i've managed to create a seemingly complete darcs convert of the cvs repo which is available at: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi (later today when the cron picks it up) darcs get --partial USER@common-lisp.net:/project/slime/public_html/darcs/slime darcs get --partial http://common-lisp.net:/project/slime/darcs/slime i've committed several fixes to the official cvs from this repo. due to the way the automated repo conversion works the ChangeLog file is not updated, but the cvs commit logs contain the full descriptions from the darcs patch. i don't know how to handle that, because all information is available in the darcs patches and hand-editing the ChangeLog file seems like a waste of time, but if the slime community would like to i can assemble some ChangeLog entries by hand after the syncs. i've got additional 3 patches that i delayed from pushing to cvs: Mon Dec 11 12:39:55 CET 2006 attila.lendvai@gmail.com * In got-xref buffer, switch the enter and space key bindings to follow the common "enter is primary action" behaviour Mon Dec 11 12:20:58 CET 2006 attila.lendvai@gmail.com * Added sldb-sexp-highlight-mode custom It controls the way sexp's are highlighted when pressing 'v' in the debugger. :mimic-paren-mode - mimic the value of 'paren-mode when available (xemacs only) :entire - highlight the entire sexp :sides - highlight only the first and last char Mon Dec 11 12:44:07 CET 2006 attila.lendvai@gmail.com * Set slime-fuzzy-completion-in-place enabled by default i think they should be in official, but they are more-or-less offending in changing the way stuff works currently. i think fuzzy should be enabled by default (for new user), and the same applies for the xref buffer space/enter. i always found that very confusing and different from everything else in emacs... the sldb sexp highlighting was removed as bloat, so i didn't commit it back (even if it works now on gnu emacs, too). but i do need a way to tell slime to highlight the entire expression when pressing 'v' because i hate looking for the carets. i think i won't commit this one except i'm explicitly asked to, but i'll commit the other two changes eventually unless someone vetoes them. i hope you find the committed changes useful, -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
"Attila Lendvai" <attila.lendvai@gmail.com> writes:
Mon Dec 11 12:39:55 CET 2006 attila.lendvai@gmail.com * In got-xref buffer, switch the enter and space key bindings to follow the common "enter is primary action" behaviour
By this you mean that enter would dismiss the buffer, whereas space would just move to the definition? Not that I deeply care either way, but can we please stick to _either_ way in all relevant buffers, and document this somewhere, so that six months ahead someone else will not feel compelled to change it the other way around? (I don't see how dismissing the XREF buffer is more primary then moving and keeping the buffer -- or vice versa.) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
* Attila Lendvai [2006-12-11 14:16+0100] writes:
dear list,
i've managed to create a seemingly complete darcs convert of the cvs repo which is available at:
http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi (later today when the cron picks it up)
darcs get --partial USER@common-lisp.net:/project/slime/public_html/darcs/slime
darcs get --partial http://common-lisp.net:/project/slime/darcs/slime
So what is the final decision in the CVS vs. Darcs question? As far as I can tell, some people were concerned about various Darcs issues and only very few were excited or felt a necessity to switch. Most people, including those who didn't comment, don't seem to care. But we are definitely not going to have two repos in parallel. Everybody who wants to actively hack on Slime should use the same code. Attila, would you please say what your plans are on the issue? If you want us to switch, you should do most of the necessary work and make the transition for everybody as smooth as possible. If you don't want the switch then please remove the Darcs repo from Slime's webspace to avoid any further confusion.
i've committed several fixes to the official cvs from this repo. due to the way the automated repo conversion works the ChangeLog file is not updated, but the cvs commit logs contain the full descriptions from the darcs patch. i don't know how to handle that, because all information is available in the darcs patches and hand-editing the ChangeLog file seems like a waste of time, but if the slime community would like to i can assemble some ChangeLog entries by hand after the syncs.
The ChangeLog is independent of the version control system. We follow GNU convention in this regard, as is documented in the HACKING file. If you didn't know about it, there's a command vc-update-change-log which generates the ChangeLog from the CVS commit messages. But usually you should write the ChangeLog entry before committing and use the log-edit-insert-changelog command to write the commit message.
Mon Dec 11 12:20:58 CET 2006 attila.lendvai@gmail.com * Added sldb-sexp-highlight-mode custom
It controls the way sexp's are highlighted when pressing 'v' in the debugger. :mimic-paren-mode - mimic the value of 'paren-mode when available (xemacs only) :entire - highlight the entire sexp :sides - highlight only the first and last char
Slime doesn't need hundreds of customization variables. What we need are good defaults.
Mon Dec 11 12:44:07 CET 2006 attila.lendvai@gmail.com * Set slime-fuzzy-completion-in-place enabled by default
i think they should be in official, but they are more-or-less offending in changing the way stuff works currently. i think fuzzy should be enabled by default (for new user), and the same applies for the xref buffer space/enter. i always found that very confusing and different from everything else in emacs...
Neither Gnus nor Rmail switch to the other buffer with RET. Which Emacs package does that? Helmut.
So what is the final decision in the CVS vs. Darcs question?
no dictator - no decisions. changes - hurt interests. no hurt interest - no voice.
As far as I can tell, some people were concerned about various Darcs issues and only very few were excited or felt a necessity to switch. Most people, including those who didn't comment, don't seem to care.
But we are definitely not going to have two repos in parallel. Everybody who wants to actively hack on Slime should use the same code.
Attila, would you please say what your plans are on the issue? If you
my plans were to keep the cvs->darcs repo in sync and to occasionally commit/send the tested changes from darcs to cvs when i happen to have the nerves for cvs. but i got tired of all this. i feel like a jerk who's just a PITA, so tomorrow i'll move the darcs repo back under cl-wdim and go quiet. i'm using slime full-time nowadays and there are many places where i quickly fix stuff and add features. most of the time these slime sessions take only a few minutes interrupting normal work (from fuzzy scoring changes to fixing wrong threads in the inspector; promptly when the issue gets over a certain annoyance limit). writing the changelog, fighting with cvs and writing these long mails take more time then the changes themselves. please don't take it as an offense but my primary goal is to make slime a better tool which is less entangling in the day work, not to agree with numerous slime hackers with numerous different goals. alright, i can hear you: i'm antisocial... so i shut up and stop being a PITA. i've reflected enough on this and currently i have no better idea that doesn't hurt *my* goals. but in spite of all this everyone's welcome to use that darcs repo or to commit stuff back into the official cvs repo from it, but unfortunately (or not) as things look now it's not gonna be an official slime repo in any way whatsoever.
want us to switch, you should do most of the necessary work and make the transition for everybody as smooth as possible. If you don't want
i've already done everything that was not way too intrusive, but i can't fix people's isp connections, i can't read docs for them and i can't (and shouldn't) decide on the fate of a several years old project with 20 patches behind me. i think there's nothing more i could do without announcing myself as the dictator - which may seem that i'm trying to, and it bothers me.
Slime doesn't need hundreds of customization variables. What we need are good defaults.
had i committed the change that highlights the entire sexp i would have gotten mails from 10 other people yelling at me why did i commit this disgusting change... sorry for the bitter mood, -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
tomorrow i'll move the darcs repo back under cl-wdim and go quiet.
done. fyi, repo is at: darcs get --partial USER@common-lisp.net:/project/cl-wdim/darcs/slime/ if anyone happens to commit patches in the darcs->cvs direction, please drop me a mail to avoid repo-conversion headaches. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
On Dec 14, 2006, at 5:48 PM, Attila Lendvai wrote:
had i committed the change that highlights the entire sexp i would have gotten mails from 10 other people yelling at me why did i commit this disgusting change...
sorry for the bitter mood,
Hi Attila, I really appreciate your efforts even if they haven't flowered here. Maybe you should start a new project: SINES (Sines Is Not Eclipse or SLIME) and build a really cool plug-in architecture so that everyone can trade SINES mods (we could cal them waves!). I'm half serious... The problem of co-mingling the work of multitudes without a dictator is _really_ hard. I wish I had a solution. thanks for your work and enthusiasm! -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
I really appreciate your efforts even if they haven't flowered here. Maybe you should start a new project: SINES (Sines Is Not Eclipse or SLIME) and build a really cool plug-in architecture so that everyone can trade SINES mods (we could cal them waves!). I'm half serious...
that wouldn't be such a bad idea but... imho major efforts should be put in swank/climacs. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
"Attila Lendvai" <attila.lendvai@gmail.com> writes:
when the issue gets over a certain annoyance limit). writing the changelog, fighting with cvs and writing these long mails take more time then the changes themselves. please don't take it as an offense
Writing the ChangeLog cannot take any longer then writing the corresponding summary as a Darcs record message, and if you don't write a summation, other people cannot easily follow what is going on. After that, it is just a question of doing cvs ci -m "really short title for this stuff". I cannot believe either of these are the issue, really. If the question of destabilizing Slime with these quick fixes becomes an issue, we can recommend FAIRLY_STABLE for most users again. So that isn't a problem either. Emails can take time, true.
but my primary goal is to make slime a better tool which is less entangling in the day work, not to agree with numerous slime hackers with numerous different goals.
I think this is the real issue here. Everything else is a distraction. I realize you may be near the end of your patience, but think about this: in the long run, either you play the game the way other Slimers do, or you end up maintaining a fork. If that's what you want to do, fair enough. Your time is not any less scarce then ours, I too have better things to do then writing these long emails. This email too has already taken more time then the INSPECT-IN-EMACS patch. Despite this I'm proofreading it again now, because I know that _your_ time is not less valuable then mine. I'm trying to save everybody's time by doing that, and I rather hope others do the same. We'd all prefer if things just went smoothly with hacking and there'd be less need to hash things over like this.
i can't fix people's isp connections, i can't read docs for them
This is totally beside the point. No-one has asked for any of these things. Let's _please_ keep this on topic and to the point.
can't (and shouldn't) decide on the fate of a several years old project with 20 patches behind me. i think there's nothing more i
Of course not. You asked for the commit bit, and (finally) you got it. Practically speaking, this means that while you get to do exactly what you will, you are also responsible for your actions. If something you commit draws heat, that's the way life works. Nothing strange or damning about it either way.
Slime doesn't need hundreds of customization variables. What we need are good defaults.
had i committed the change that highlights the entire sexp i would have gotten mails from 10 other people yelling at me why did i commit this disgusting change...
This is another distraction. I say it's better to commit a change plus whatever customization variables it needs, and wrangle over it later. The correct amount of customization is to a degree a matter of taste. - Someone commits a new feature. - Time passes... - Someone removes the feature as a part of a cleanup. - Argument ensues. - A solution is arrived at. This is the way things work. Of course one can talk about it before removing some feature, but: willingness to talk things out when disagreement arises is essential. Anyone who is not willing to do that is going to run into a wall sooner or later -- with Slime or otherwise. ... Frankly, if it settles down the dust, I'd be willing to move Slime to Darcs + monthly timeboxed releases. I'm not willing to move Slime to Darcs and retain current "release practise", though -- Darcs is still esoteric enough to make that a bad proposition in my mind. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
I realize you may be near the end of your patience, but think about this: in the long run, either you play the game the way other Slimers do, or you end up maintaining a fork. If that's what you want to do, fair enough.
imho, slime is naturally a project of many branches because everyone has their own desires that may or may not be meant for public consumption. darcs is a great tool for that (when used properly*), because its internal state is a semi-ordered list of diffs, where the ordering is the dependency between the diffs on line-level granularity. as long as you record independet patches you can freely transfer them between the branches as simply as a 'darcs pull'/ or 'darcs push' and therefore each copy of a repo is a branch on its own right. so with darcs you can exchange patches like stamp collectors exchange stamps: just announce a cool patch on the list with a repo link, then people can pull it from you and those with the commit bit can push it into the official branches. this is this simple as long as the patches are recorded in repos that are sufficiently close to each other on the darcs patch level. (*) always record the smalles possible semantical unit of changes as a patch. do not record deeply nested conflicting patches in different, real** branches because they are a headache when all of them are pulled into a single repo (the simplest problem is a necessity of hand resolution of conflicts, while the biggest is a current darcs deficiency about an exponential algorithm never finishing. this renders the patches incompatible until it's addressed by the darcs devs. but you need two fairly different branches with active development in both of them to be able to record such patches). (**) you can have simple branches like the dev/stable that are not really branches, only there's a delay in the patches arriving to stable. and you can have "real" branches when you record changes in more then one repo simultaneously which makes it possible to record actually conflicting patches.
i can't fix people's isp connections, i can't read docs for them
This is totally beside the point. No-one has asked for any of these things. Let's _please_ keep this on topic and to the point.
i was just reacting to actual cons brought up against darcs here.
Frankly, if it settles down the dust, I'd be willing to move Slime to Darcs + monthly timeboxed releases. I'm not willing to move Slime to Darcs and retain current "release practise", though -- Darcs is still esoteric enough to make that a bad proposition in my mind.
i think it would be enough to have two (or more) official branches like slime.stable, slime.dev, etc where people are liberal in pushing to the dev branch and only pull patches to the stable branch from the dev branch with a delay (and consensus on questionable changes). there's also darcs undo to easily record a reverse patch when there's a veto. (unpulling from a public official repo is a no-no because some users may have pulled the patch already) then less active users can choose the stable branch and the more active users can use the dev branch. and even they can remove a problematic patch from their local repo as easily as a 'darcs unpull' while the debate is going on on the list. now this all is much less convenient if the stable branch is a cvs repo and i'm the only one using the darcs repo (currently at http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-wdim-slime;a=summa... ), but it's still simpler for me as long as the two repos are sufficiently close to each other (and therefore there are no, or only a few conflicts while converting the cvs chages into the darcs repo). i hope this makes it clear why i prefer to use darcs and that it's not an intention of mine to maintain a fork. btw, in the current situation i don't consider the darcs repo as a fork, only a convenient way to store our (the dev team i'm working in, Levente made the new in-place fuzzy gui) changes and distribute them between us (and anyone interested). -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
On 12/16/06, Attila Lendvai <attila.lendvai@gmail.com> wrote:
I realize you may be near the end of your patience, but think about this: in the long run, either you play the game the way other Slimers do, or you end up maintaining a fork. If that's what you want to do, fair enough.
imho, slime is naturally a project of many branches because everyone has their own desires that may or may not be meant for public consumption.
The project survived without branches for a really long time. Wouldn't it become more complicated to all the slime users (especially ones that are not subscribed to the list) if we had multiple repositories with different sets of features/goals?
darcs is a great tool for that (when used properly*)
(*) always record the smalles possible semantical unit of changes as a patch. do not record deeply nested conflicting patches in different, real** branches because they are a headache when all of them are pulled into a single repo (the simplest problem is a necessity of hand resolution of conflicts, while the biggest is a current darcs deficiency about an exponential algorithm never finishing. this renders the patches incompatible until it's addressed by the darcs devs. but you need two fairly different branches with active development in both of them to be able to record such patches).
(**) you can have simple branches like the dev/stable that are not really branches, only there's a delay in the patches arriving to stable. and you can have "real" branches when you record changes in more then one repo simultaneously which makes it possible to record actually conflicting patches.
Why not use bzr[1] or git[2] or even subversion[3] (yep a slightly better support for branches would be enough as slime doesn't really need a distributed development model) then? Both of them are a lot more stable when it comes to huge diffs, conflicts, extra files in the repository and for someone coming from CVS the loss off the interactive hunk picking (bzr/git don't have this one) won't be such big a loss. [1] http://bazaar-vcs.org/Bzr [2] http://git.or.cz/ [3] http://subversion.tigris.org/
now this all is much less convenient if the stable branch is a cvs repo and i'm the only one using the darcs repo (currently at http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-wdim-slime;a=summa... ), but it's still simpler for me as long as the two repos are sufficiently close to each other (and therefore there are no, or only a few conflicts while converting the cvs chages into the darcs repo).
i hope this makes it clear why i prefer to use darcs and that it's not an intention of mine to maintain a fork. btw, in the current situation i don't consider the darcs repo as a fork, only a convenient way to store our (the dev team i'm working in, Levente made the new in-place fuzzy gui) changes and distribute them between us (and anyone interested).
The downside is that darcs would make it more difficult for people using slime on mac, windows, some flavours of unix (a lot of programmers) to use and would make it easier for you and your co-workers to develop (not so many programmers) or would add additional work for main developers of slime (they would have to make additional tar.gz releases, learn a new version control system) Though I think darcs is superior to CVS IMHO it would solve problems to a very narrow group of people while creating at least some problems to a lot of slime users. Just my 2 cents. Ignas Mikalajūnas
imho, slime is naturally a project of many branches because everyone has their own desires that may or may not be meant for public consumption.
The project survived without branches for a really long time. Wouldn't
just like many programmers survived with c (i'm honestly sorry for this strike, but i just couln't help it... :)
it become more complicated to all the slime users (especially ones that are not subscribed to the list) if we had multiple repositories with different sets of features/goals?
they don't have to know about any of this: one big command line ready to be copy-pasted that gets the official stable repo. and i only proposed 2 repos with and extra temporary third one when there's some huge change that renders slime temporarily unstable. but slime will probably never have such a refactor.
Why not use bzr[1] or git[2] or even subversion[3] (yep a slightly better support for branches would be enough as slime doesn't really need a distributed development model) then? Both of them are a lot more stable when it comes to huge diffs, conflicts, extra files in the repository and for someone coming from CVS the loss off the interactive hunk picking (bzr/git don't have this one) won't be such big a loss.
ymmv. i tried the distributed model and i never looked back (see my previous mail for reasons).
[1] http://bazaar-vcs.org/Bzr [2] http://git.or.cz/ [3] http://subversion.tigris.org/
in my point of view, subversion is out of the scope because it's not a distributed source control system (it's basically cvs rewritten). bazaar and git both use the same basic idea that darcs. they are like different implementations of it, so much so that newer darcs binaries will support git repositories (details: http://darcs.net/DarcsWiki/DarcsGit ). i must admit that i don't know bazaar and git too well, but on the other hand darcs never made my life hard (well, maybe sometimes, but never without a valid reason that could have been avoided). and i have a local darcs repo of dojo with a size that is not even comparable to slime. on the other hand darcs can apply patches that change files that were meanwhile renamed by another patch. and features like that... also bazaar seems to have a bad reputation (without me having first-hand experience with bazaar, this guy sounds reasonable): http://www.kdedevelopers.org/node/2024 oh, and the first thing you can read on git's site is this: "Git - Fast Version Control System" :)
The downside is that darcs would make it more difficult for people using slime on mac, windows, some flavours of unix (a lot of programmers) to use and would make it easier for you and your co-workers to develop (not so many programmers) or would add additional work for main developers of slime (they would have to make additional tar.gz releases, learn a new version control system)
again, i'm fine and i don't really want to convert anyone or anything anymore. but i must tell here that i used darcs both on windows and on linux and it was working out of the box. if you want to commit stuff then you must set up an ssh login with keys (unless you are ready to enter your ssh password a thousand times), but that's documented all around on the net ranging from putty to cygwin's ssh. i don't know about mac in particual, but this page has binaries not only for mac but even for solaris and aix: http://darcs.net/DarcsWiki/CategoryBinaries
Though I think darcs is superior to CVS IMHO it would solve problems to a very narrow group of people while creating at least some problems to a lot of slime users.
any kind of change in any aspect of life means that you need to leave a local minimum of "energy consumption" in the hope of reaching a better one. it's just like when you learn a new language, but i guess i don't need to go into the details of this particular tought on this particular list... :) my envisioned model with darcs is not so much about solving problems then opening new possibilities (which seems like the majority of the slime devs are not missing or they just don't care enough to speak up, and therefore i started to consider the effort of trying to move away from the current local minimum more pain then what it's worth for me). iow, i started to consider less pain to pack up my patches in my backpack and climb that mountain occasionally when the need comes, then trying to move the village... sorry for the silly methaphore... :) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
they don't have to know about any of this: one big command line ready to be copy-pasted that gets the official stable repo.
The point of my rant was to say that: darcs is not universally available on as many computers as CVS is. Even svn sometimes is a bad idea, because it is less widespread than CVS is. Making users download darcs to use slime might be a bit too much (ymmv though)
in my point of view, subversion is out of the scope because it's not a distributed source control system (it's basically cvs rewritten).
Sorry for the misunderstanding, I thought that you wanted the switch to make your use-case easier to support, but apparently you want to convert slime developers to darcs users.
any kind of change in any aspect of life means that you need to leave a local minimum of "energy consumption" in the hope of reaching a better one. it's just like when you learn a new language, but i guess i don't need to go into the details of this particular tought on this particular list... :)
The benefit for developers (some), the pain for users (some). The problem is that one is getting and another one is paying the price. Ignas
The benefit for developers (some), the pain for users (some). The problem is that one is getting and another one is paying the price.
the "users" of slime are developers. i may be way too short-sighted on this but i can't imagine that more then a marginal fraction of slime "users" need to install darcs only because they want to get the latest slime. but this is getting more about protecting different point of views then a fruitful discussion about how to make things work better. i proposed something i think is better for everyone, i made my share of the work, and i'll let it die unless others back up behind the idea. (which means that there's no need to argue _against_ darcs while i'm alone, because nothing will happen to the official slime repo) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
On Dec 17, 2006, at 9:03 AM, Attila Lendvai wrote:
The downside is that darcs would make it more difficult for people using slime on mac, windows, some flavours of unix (a lot of programmers)
FWIW, I use darcs under Mac OS X with no troubles. It works great. -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
Helmut Eller wrote:
So what is the final decision in the CVS vs. Darcs question?
As far as I can tell, some people were concerned about various Darcs issues and only very few were excited or felt a necessity to switch. Most people, including those who didn't comment, don't seem to care.
As a mere user, I prefer CVS if only because I don't want to install darcs. If it ain't broke, don't fix it. :-) FWIW. Ray
On Jan 6, 2007, at 5:58 AM, Raymond Toy wrote:
Helmut Eller wrote:
So what is the final decision in the CVS vs. Darcs question?
As far as I can tell, some people were concerned about various Darcs issues and only very few were excited or felt a necessity to switch. Most people, including those who didn't comment, don't seem to care.
As a mere user, I prefer CVS if only because I don't want to install darcs.
If it ain't broke, don't fix it. :-)
FWIW.
Ray
I vote to stay with CVS. jjm
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Yes, and it wouldn't be too simple to switch to darcs, because I'm on freebsd amd64; and there still is no amd64 port of ghc and darcs depends on it. 'Andreas -- Wherever I lay my .emacs, there's my $HOME.
As a mere user, I prefer CVS if only because I don't want to install darcs.
If it ain't broke, don't fix it. :-)
not that it matters, but it's not about anything being broken, but missing useful features. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)
Raymond Toy <toy.raymond@gmail.com> writes:
Helmut Eller wrote:
So what is the final decision in the CVS vs. Darcs question?
As far as I can tell, some people were concerned about various Darcs issues and only very few were excited or felt a necessity to switch. Most people, including those who didn't comment, don't seem to care.
As a mere user, I prefer CVS if only because I don't want to install darcs.
If it ain't broke, don't fix it. :-)
One thing I miss in CVS is that it doesn't work over http (at least I am not aware of such a CVS feature). If I am behind a firewall that only allows http, I still can use darcs, i.e.: darcs get htp://someplace.com/darcs-repo Is there any way to do this with CVS? -- vedm
participants (10)
-
Andreas Eder -
Attila Lendvai -
Edi Weitz -
Gary King -
Helmut Eller -
Ignas Mikalajunas -
Joshua Moody -
Nikodemus Siivola -
Raymond Toy -
vedm