[slime-devel] Re: cvs committed darcs changes

Ignas Mikalajunas ignas.mikalajunas at gmail.com
Sun Dec 17 12:41:30 UTC 2006


On 12/16/06, Attila Lendvai <attila.lendvai at 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=summary
> ), 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


More information about the slime-devel mailing list