gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: darcs vs tla


From: Thomas Lord
Subject: Re: [Gnu-arch-users] Re: darcs vs tla
Date: Thu, 11 Nov 2004 14:34:54 -0800 (PST)


First: I think you win the "best (extended-)ascii art of the month",
award, for a g-a-u post.


Next:

  > (Does that sound insulting towards Darcs?   It doesn't at all if you
  > regard darcs as a short-term R&D exploration.)

  What it sounds like you are saying is:

  "The only thing darcs has going for it is some wacky merge operator
  that we could implement, if someone actually wanted it. Other than
  that it has nothing of value and is doomed to obscurity."

  It would be a lot nicer if you sounded like you were saying:

  "The darcs core technology does not seem to have an inherent advantage
  over arch, but the user experience totally blows tla out of the
  water. We must make the new user experience for tla superior to darcs
  and svn, or we will arch will be doomed to obscurity."


More like "Darcs' primary advance, in core technology, is its merge
operators.   Darcs appears to miss much of arch's capabilities in this
area, but it also appears to make a novel contribution with its
variance-adjusted approach to patch commutativity.   Archers should
evaluate those new merge operators and consider the question of
whether or not they are worth adding to arch, although I'm personally
skeptical because of the nature of variance adjustment."

Your point, about UI, is a separate topic, in my book.   On that topic
you are quite correct, I think.   

The little micro-project I'm working on now (the mess at
http://gnuarch.org is actually a snapshot of the source tree) is a
wrapper that shows how higher-level commands can be built on arch for
a particular project process, fairly quickly and cheaply.   I have,
for example, 'gtla make-fork' which knows how to set up all the
branches needed to fork from the GNU Arch mainline (and, with an
upstream tweak in configuration, any other project).   I'm working on
similarly high-level/gentle commands for maintaining "contribution
branches" and for cherry-picking from the contribution branches of
others, etc.

So, yeah, the UI issues you cite are real but they're also what's
currently being addressed.

It won't ever be possible to /entirely/ match the minimalism of the
darcs interface you illustrated, simply because things aren't really
that simple.

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]