[darcs-users] dvcs article
Trent W. Buck
trentbuck at gmail.com
Wed Feb 4 00:22:51 UTC 2009
Matthias Andree <matthias.andree at gmx.de> writes:
> zooko schrieb:
>> On Jan 24, 2009, at 8:41 AM, Tommy Pettersson wrote:
>>> Darcs (and SVK) are "not recommended", because the alternatives can
>>> all handle large repos, whereas darcs can not
>> Sounds like a reasonable recommendation. I would be interested in
>> having some automated generation of graphs of darcs performance and
>> scalability, generated by the buildbot.
>>> The article also describes darcs' repo-is-a-branch-is-a-repo as
>>> inflexible compared to the competitors. This puzzles me, because I
>>> find this freedom *extremely* flexible. But I have not used any of
>>> the other systems, so I don't know what I'm missing out on.
>> Yes, this is a common criticism of darcs. I can't tell whether there
>> is really some advantage to the way other dvcs's have separate
>> notions of branches and of repos, or whether the users of those
>> systems are mistakenly thinking that darcs's branch==repo causes some
>> problems that it doesn't.
> The point is that Mercurial and Git can of course support DARCS's model.
> You can clone and use shared repos if you want the branch == repo model.
> The notable difference is that Git stores patch ancestry and
> "cherry-picking" (Git) a patch or "transplanting" (Mercurial) is not the
> same as DARCS's commutable patches.
> The advantage in Git (apparently also in Mercurial, but I really don't
> know that too well) is that with local branches you only have one repo
> copy, and you can switch between branches fast. And I mean really fast.
> I'd probably use the clone-for-branch approach if I wanted two separate
> working trees, and local branches otherwise.
> Conventionally, Mercurial seems a bit closer to DARCS's model in that it
> has apparently not encouraged local branches as strongly as Git has, but
> that's not a technical reason AFAICT, but just common use of lead
The technical reason might be that hg's "update" command, which is used
to change between in-branch heads, tends to be make my repo explode in a
fashion that I cannot work out how to recover from, and therefore I have
to make a completely fresh clone of upstream and re-record all my
patches by hand.
This has happened several times for me with hg merely because of a merge
conflicts between my HEAD and upstream's HEAD; the result being that I
actually have to use hg more like svn than a dVCS -- frantically pushing
changes back upstream after every commit, in constant fear of a merge
More information about the darcs-users