Re: [darcs-users] so long and thanks for all the darcs

[Stephen J. Turnbull]

Ben Franksen writes:
 > Hi Stephen
 > 
 > Am 08.03.2018 um 09:52 schrieb Stephen J. Turnbull:
 > > Another long one.  But we're converging!
 > 
 > Indeed. I think we agree on almost every point,

I think so, at this point.  You added some stuff that I don't disagree
with but think I can shed some additional light, or provide an
alternative view.

 > > I don't consider this an attitude, but rather a fact.  
 > 
 > Just to note, I meant "attitude" in a neutral sense, not with an
 > implied connotation of "youthful" or "uneducated". There are people
 > who just want

I understood the neutrality.  My point was simply that even if you're
personally disposed to the wild branching style that Tom Lord
encouraged in Arch and you still see in some GitHub repos, it's a fact
that your life is often simplified if others have to move straight
ahead.

 > Certainly. But I think we should distinguish here between public
 > (shared) branches and unpublished (local, one developer)
 > branches. The latter are unavoidable in practice and I would not
 > use anything that did not allow me to have several local branches
 > for the different things I am working on (in parallel or
 > intermittently). The former can be problematic but (at least with
 > Darcs, as it currently is) the main problem IME is not merge
 > conflicts but discoverability!

Sure.  You can't get into a conflict with a branch you never tried to
merge because you didn't know about it.  I think what you're seeing
here is a form of selection bias.  It will be interesting to see if
patch theory really is powerful enough to keep conflicts manageable
when you're looking at something like git.kernel.org with 25 core
developers maintaining an average of 2.5 branches each, and fans
feverishing trying all possible merges. :-)  My guess is "no", but it
would be very cool if I were proved wrong!

 > > Well, there's also functional programming.  C, for all its faults, is
 > > an imperative language, and people seem to find that easier to grasp.
 > 
 > I don't buy that. The Haskell community is large enough nowadays. It's
 > just that nobody is interested because 10 years ago they (almost) all
 > moved to git.

It doesn't matter how big the community of capable programmers is,
unless it's so small it constrains how big the intersection with your
community of users can get.  It's that latter that matters.  I agree
that GHC moving to git was a huge blow to Darcs in this way.

 > Besides, large parts of the existing Darcs code aren't very
 > "functional" to start with.

Sure, but the idioms needed to program in imperative style in Haskell
don't look imperative to relatively naive users.  Remember, to add new
features in git you only need a language that can call the "plumbing"
functions and catch stdout, name the program with the "git-" prefix,
and put it somewhere on PATH.  That Linus guy is crazy like a fox!
Then to make it efficient, translate to C.  Most languages look enough
like C (or support imperative idioms) to make this straightforward.

 > FWIW, I think that pulling from a repo with more than one branch should
 > fail if no branch is given explicitly and no default has been specified
 > locally. With an error message that says "Sorry, I have no idea which
 > branch you want to pull from"

That is what happens with git.

 > followed by a list of available branches or a hint to which command
 > to use to list them.

I don't think this is possible with raw git on a remote repository.  I
believe you need to fetch all the remote refs, and query locally.

 > Perhaps, what drives the complexity of the branch handling over the
 > edge in git is that they chose to give local names to remote
 > branches.

Well, git simply doesn't "do" remote branches the way that Mercurial
and especially Bazaar do.  Yes, you could enhance git to have a
distributed DAG quite easily, but what users manipulate as "branches"
are nothing more than local variables pointing to head commits.  So
the solution the git developers came up with was providing namespaces
(called "remotes" in git documentation) so that one name could refer
to several heads at the same time.  (In practice, there's no way to
change the default namespace, so to refer to a name in a non-default
namespace you need to spell out the remote, e.g., "origin/test"
vs. "test" in the example you gave.)

What you described as "linking at clone time" is exactly what git
does: it automatically copies the specified branch ref (default
"master") from the "origin" namespace to the default (unnamed)
namespace.  It is strongly discouraged, though not impossible, to
change refs in a remote's namespace locally.

 > Git complains, too, IIRC, and as usual with its own rather cryptic
 > language (the "you are in detached HEAD..." sermon).

But to get that message you need to explicitly checkout a commit that
is not the target of a branch ref.  This occasionally saves typing,
but is never necessary, and never happens via pull or push.

In Mercurial, 

Re: [darcs-users] so long and thanks for all the darcs

[Stephen J. Turnbull]

Another long one.  But we're converging!

Ben Franksen writes:
 > Am 05.03.2018 um 04:40 schrieb Stephen J. Turnbull:

 > > Although git and Mercurial (and Bazaar) share a repository model that
 > > is somewhat more complex (DAG of versions), only git's implementation
 > > is faithful with an immutable representation of history.  Mercurial's
 > > and Bazaar's implementations violate faithfulness and immutability, so
 > > their designers chose to restrict the operations available for safety
 > > and simplicity.
 > 
 > Do you have any references supporting this assertion? It is the first
 > time I have seen it made and are somewhat perplexed (and intrigued).

I don't have a reference to the intent of the designers of Mercurial
and Bazaar as such, but they have frequently made the point that they
are safe, criticized git for permitting dangerous operations, and it's
easy to observe that they're restricted relative to git.

 > > I have two questions about current darcs:

Thank you for your careful answers.

 > We have the 'darcs test' command. I believe it is similar to git's
 > bisect, see 'darcs test --help' for details.

Ah, I did know that, but got hung up on "bisect" which doesn't make
sense as a command name when patches don't always have dependencies or
dependents.

 > In darcs tags are also just patches, but if you pull a tag you get the
 > tag itself, too (since this is how it works: a tag artificially depends
 > on all patches present when you create it).

Yeah, this kind of thing is what I mean by saying Darcs's
implementation is faithful to its mental model.

 > I must say I don't really understand what you are saying. What does
 > "people like to reify branches" mean, exactly?

It means that they think of them as separate entities, backed by some
data structure in the implementation.  For branch-per-repo models, the
repo is that data structure.  In addition, Bazaar has a whole internal
API that knows all about manipulating branches, as opposed to the
history they contain.  Mercurial has this odd branch name property on
commits.

By contrast, in git there's the history DAG and its components
(commits, trees, and blobs) and that's it.  The DAG may have multiple
heads, and what people think of as "the branch I'm working on" may not
even be entirely contained in the repository.  There is no data
structure that surely contains everything you need to know about a
branch, except the whole repository plus any external object databases
configured in the repository's metadata.

 > > It's very hard to get Darcs' "set of patches" model wrong.  I think
 > > that's part of the appeal of Darcs.
 > 
 > The "set of patches" model can be misleading.

You're right.  That was very sloppy of me.  What I meant was a partial
order (with patches being related if one is dependent on the other).
But that's not very useful to people who haven't gone down that
mathematical rabbit hole.  Everybody knows what a sequence is.

 > > Another part is the appeal to fans of the so-called "user-friendly"
 > > VCSes that there's very little you can do except move straight ahead,
 > > but that also means everybody else has to move straight ahead, too.
 > > This simplifies life dramatically most of the time.
 > 
 > Yes, I see this attitude a lot with (some of) my co-workers.

I don't consider this an attitude, but rather a fact.  Specifically,
there are many costs to working on branches: redundant work
accomplishing the same task, arguing which implementation is the
redundant one, merge conflicts, etc.  I think the benefits exceed the
costs by far, but I admit there have been times when I've been
massively frustrated by a colleague pulling the rug out from under my
feature branch.  I'm comfortable with people who have fairly extreme
views in that direction; maybe they had even worse experiences than I
have had!

 > Yes. Efficiency and extensibility are the two major weak points of
 > Darcs. This, apart from a large user base and the usual network
 > effects, is part of why git attracts developers and Darcs does
 > not.

Well, there's also functional programming.  C, for all its faults, is
an imperative language, and people seem to find that easier to grasp.

 > We don't have a "kernel" with a stable API,

git doesn't have a stable API either.  I don't know about the current
developers, but Linus basically promised that the *UI* would be
backward compatible.  Any scripts you've written will continue to
work.  The internal APIs are subject to change, though, and that's why
there's never been a successful refactoring into a "libgit" plus CLI
module.

 > I should mention here that the "set" of patches in darcs is also a DAG,
 > just not /explicitly/ so.

Sure.  The DAG I'm talking about is a completely arbitrary history
DAG.  The dependency DAG of Darcs is a different thing.

 > Yes, there is a difference when it comes to branches. I am not sure I
 > know what you mean with "in Mercurial [...] there's only one per repo in
 > practice".

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 13.04.2018 um 10:19 schrieb Stephen J. Turnbull:
> Benjamin Franksen writes:
>  > On 04/10/2018 08:34 AM, Stephen J. Turnbull wrote:
> 
>  > > Any user who understands what a ref is will say "a Darcs tag is
>  > > too a ref!" I think.
>  > 
>  > Perhaps (but you won't, right?).
> 
> I would, in the sense that it is a name that allows you to rebuild a
> version exactly, just as a git tag or branch does.  It's not a ref
> into a DAG, of course.

That's what I meant.

>  > > How do you identify "official"?
>  > 
>  > I can't, unless it's an "official" repo to start with (e.g.
>  > http://darcs.net/) and then I would assume that all branches are
>  > "official" (assuming darcs had branches).
> 
> This is generally not true with git.  In corporate situations,
> including large volunteer projects like Python or GHC, it probably is
> true.  But in cases of smaller projects, or even projects with formal
> organizations that translated repos from centralized systems where
> public branches were an important form of communication, I would
> expect a lot of detritus.

But in principle it seems we agree that branches in a public, shared
repo should not be used, nowadays, to publish e.g. some experimental
development. There should be a better (clearer, more explicit) way to
communicate/publish work that deviates from the shared baseline(s) of
"officially accepted" branches in a project. The "fork" feature of
github is indeed a pretty good solution, except that it is tied to one
central service. I think I need not re-iterate here the reasons why
depending on a single service is problematic, particularly if running
such a service is subject to commercial interests.

So I would like to have something more "distributed" in nature, similar
to peer-to-peer file sharing, with one or more competing services that
merely act as a directory for searching and discovering related repos
(and, perhaps, communication i.e. pull requests), and other services
where repos and/or bug trackers are hosted. For a smooth user experience
this would require some common protocol for all this higher level
information. Perhaps one day someone develops something like that.

> Also, many projects make official "release branches".  Python has
> several score by now.  In the Mercurial days, each was a separate
> repo, but in git there's been substantial merging.  I'm not sure if
> they've *all* been aggregated into one repo, but the backports policy
> suggests they might have, for convenience in cherry-picking.

Release branches are the prototype of what I meant with "official branches".

>  > > I doubt they'd be willing to make "export all branches on clone"
>  > > a default, and it's not clear to me that the "I just want to see
>  > > the mainline" aren't the majority.
>  > 
>  > How do they identify "the mainline"?
> 
> To the folks who just want the VCS to stay out of their way, it's
> "whatever $VCS clone scheme://project.org/official checks out."

This would not work for at least one project I am maintaining. I have
several equally usable and maintained branches (versions). It is true
that serious development happens only on the latest version, but due to
its instability potential contributors would most probably want to
target a more stable release because this is what they use. It depends
on what kind of contributions are expected: occasional bug fixes and
minor improvements, or substantial contributions for new features.

So I maintain that, at least in /my/ experience, there are cases where
this "one default mainline branch" is not appropriate.

> You mentioned "familiar and comfortable with Darcs".  I don't think
> "comfortable" implies "familiar" (in the sense of how the internals
> work and how it differs from other VCSes the user may be comfortable
> with).

I meant "familiar" not with how the internals work but with the UI and
the user level idioms, i.e. the ability to use it effectively and with
confidence (regarding the outcome of commands issued).

(An exception for Darcs is the patch matching options which are messy
and interact in strange and sometimes unpredictable ways. Cleaning that
part up has been on my TODO list for a long time.)

> I think it means (to most users) that the VCS stays out of their way.

I can't speak for "most users" but for me it is a way to structure my
work and thus I expect more than that it stays out of my way. There is
no way around the fact that VC has a great influence on the way you work
and how you share and co-operate with others, very much like the choice
of programming language does. I have long since decided to embrace it
and use it to improve what I am doing and the way I do it. I am using
Darcs even for activities that have nothing to do with programming (e.g.
I've written a short story once and as a matter of course I kept the
text under Darcs control).

>  > Indeed. At work we use Darcs for development of several medium sized
>  > control systems for scientific instruments.
> 
> 

Re: [darcs-users] so long and thanks for all the darcs

[Benjamin Franksen]

On 04/10/2018 08:34 AM, Stephen J. Turnbull wrote:
> Ben Franksen writes:
>  > Am 29.03.2018 um 10:08 schrieb Stephen J. Turnbull:
> 
>  > Internally we do use references, similar to git (we refer to patches,
>  > inventories, and trees via content hash). But in contrast to git, these
>  > are not exposed as a user visible concept. Tags are somewhat special;
>  > they do serve to identify versions, i.e. what git uses refs for. But
>  > since their behavior is specified in terms of patch dependencies, they
>  > are not really an exception to the rule.
> 
> I think you're taking the implementation too seriously. 

That comes from talking too much about git ;-)

> Any user who
> understands what a ref is will say "a Darcs tag is too a ref!" I
> think.

Perhaps (but you won't, right?).

>  > > I would think "link 'em all" is a better default for most projects,
>  > > except that in git branch refs are really lightweight, so developers
>  > > are likely to have a bunch of obsolete or experimental branches lying
>  > > around that you don't want.
>  > 
>  > Good point. I was thinking about "official" branches only, not
>  > experimental/feature/whatever branches that anyone can and does create
>  > all the time.
> 
> How do you identify "official"?

I can't, unless it's an "official" repo to start with (e.g.
http://darcs.net/) and then I would assume that all branches are
"official" (assuming darcs had branches).

>  I think that by now the great
> majority of git users use it because their projects are hosted on
> GitHub or GitLab, and mostly it's obvious what the "official" branches
> are. 

Yes.

> But the maintainers of git, who target themselves in designing
> new features for it, are very much peer-to-peer sharers, cloning or
> pulling branches from a wide assortment of repos.  This is what
> "distributed" means to them.  I doubt they'd be willing to make
> "export all branches on clone" a default, and it's not clear to me
> that the "I just want to see the mainline" aren't the majority.

How do they identify "the mainline"?

>  > > This is how Subversion works (and CVS before it and Bazaar
>  > > "lightweight checkouts" after it).  With that restriction, distributed
>  > > development is painful.  Avoiding that restriction is why Arch,
>  > > BitKeeper, git, Mercurial, Monotone, Bazaar, ... were developed.
>  > > Darcs, too. :-)
>  > 
>  > I don't understand. What has distributed versus centralized to do with
>  > it? I'd say in a centralized system there is only one "remote", so the
>  > question is moot. Is that what you mean?
> 
> No, it's not.  By distributed *development* (as opposed to distributed
> VCS), I mean a situation where multiple people are updating a single
> mainline.  Even with distributed VCS, there's normally an "official"
> repo with an "official" master branch in it. 

Indeed. At work we use Darcs for development of several medium sized
control systems for scientific instruments. The largest has about 10
process variables and is distributed over almost 100 I/O controllers.
Patches are pushed to the central repo by 14 developers. We almost never
have conflicts because people tend to work on different parts. I usually
have a hand full of "feature branches" locally, where I keep stuff that
isn't ready for production; but for minor changes I just use an
up-to-date clone of the central repo (i.e. one where I have no local
patches and where I just pulled), make the change, record it, and push.

(Note that push does not mean it goes into production immediately, there
is a separate distribution step. This process also records a snapshot of
the state of the source tree using 'darcs log --context', which is
occasionally useful for forensics.)

It is an extremely smooth process and the way we use it really is
"distributed development".

> This means that from an
> individual developer's point of view, the state of master is a triple:
> (1) what's actually in the official repo (unknown; another dev may
> have updated),

True. (Though it is easy to check if this is the case (hg incoming,
darcs pull --dry-run, git )).

> (2) what's recorded in your workspace's metadata, and 
> (3) what's actually in your working tree.[1]
> A centralized VCS doesn't allow you to commit unless (1) == (2).  A
> distributed VCS does.  But I think a lot of users' intuitions are
> informed (though not fully determined) by this constraint that (1) and
> (2) are supposed to be "the same".

Perhaps people who have worked with CVS or Subversion for years, but
certainly not people familiar and comfortable with Darcs.

>  > This is all uncontroversial IMO and has nothing to do with the
>  > question we are discussing.
> 
> This makes me unsure what you think the questions we discuss are.

I am unsure myself because I have lost some of the context.

> I
> think that one question is about how in a DAG-based system it's always
> possible to identify all past states of all relevant upstream branches
> (although you may 

Re: [darcs-users] so long and thanks for all the darcs

[Evan Laforge]

By the way, I found this thread really interesting and informative,
and learned some things about git and version control.  So thanks for
the discussion.

Content-addressed storage is pretty interesting.  There was actually a
filesystem based on this, for Plan 9, called fossil.  It was a true
write-only filesystem and had some interesting properties that are
somewhat reminiscent of git.  The paper is a good read, like all the
plan 9 papers.

Another random aside, is that one of the things that broke when I
ported from darcs to git is that git removed the empty directories.
It turns out git doesn't support empty directories at all.  Of that's
due to how they implemented content-address storage and not the idea
itself, but it's still a bit of an awkward side-effect, along with the
more well-known "doesn't really support renames" one.
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 29.03.2018 um 10:08 schrieb Stephen J. Turnbull:
> Ben Franksen writes:
>  > If yes, then I begin to understand why as a Darcs user I found it so
>  > difficult to become familiar with git. Because this concept of a "ref"
>  > has no (user visible) counterpart in Darcs. It doesn't exist because it
>  > is not needed (for the user). We /could/ add something like it so we can
>  > refer to patches symbolically, but AFAIK nobody has ever found it useful
>  > enough to request it as a feature.
> 
> That sounds almost right to me.  The exception is a tag, which is
> present in Darcs and induces a version via its dependencies, whereas
> in a DAG-based VCS it is a ref, and points to a version in the history
> graph.

Internally we do use references, similar to git (we refer to patches,
inventories, and trees via content hash). But in contrast to git, these
are not exposed as a user visible concept. Tags are somewhat special;
they do serve to identify versions, i.e. what git uses refs for. But
since their behavior is specified in terms of patch dependencies, they
are not really an exception to the rule.

>  > Whereas in git the concept is essential because many of the high-level
>  > features that make git usable as a tool for day-to-day work are built on
>  > it.
> 
> In fact, any DAG-based VCS requires refs.  Mercurial and Bazaar add a
> sequence number ref type (and in Bazaar it's actually a structured
> sequence number which identifies the branch and version relative to
> the branch point, recursively \o/).

Okay. I see how git may look simple when you compare it with bazaar...

>  > The core of git is sound, simple, and elegant; but the high-level
>  > features that build on it have been developed in an ad-hoc manner
>  > without an over-arching and similarly elegant abstraction to guide the
>  > design, so it remains necessary to understand the mechanism behind them
>  > in order to use (and appreciate) them appropriately. I think /this/ is
>  > the deeper reason behind git's "bad UI" reputation.
> 
> From my point of view, all you've said is "people don't grok DAGs". :-)

Ah well, i do keep telling people that the memory in their computers is
nothing but an array of bytes, but they still find them complicated, so
perhaps they just don't grok arrays?

This reminds me of the old haskell joke "A monad is just a monoid in the
catgory of endofunctors, what's the problem?". What I personally find
funny about this is that it's actually true and I don't mean in the
mathematical sense. The concepts mentioned in this short sentence are a
lot harder to understand than "DAG" or "array", but once you do,
actually using them in a way that reliably gives you the results you
expect is quite simple. Whereas understanding the array concept is easy
but using them is frought with hazards (especially if you assume
everyone has access to every element and can modify it at will...).

>  > > but only the currently checked out one at remote is linked to a local
>  > > branch, and checked out locally. Configuration ("core" options in 
>  > > .git/config) comes from your local template, I believe.
> 
>  > Okay. I would expect that all local branches are initially linked to
>  > their remote counterpart.
> 
> This would be really ba-a-ad if you were working on the kernel where
> everybody is cloning everybody else's repos all the time.  The git
> developers all are kernel developers. ;-)

I don't get why this would be bad, except...

> I would think "link 'em all" is a better default for most projects,
> except that in git branch refs are really lightweight, so developers
> are likely to have a bunch of obsolete or experimental branches lying
> around that you don't want.

Good point. I was thinking about "official" branches only, not
experimental/feature/whatever branches that anyone can and does create
all the time.

(But then you also don't want the commits on these branches, right?)

Which is the better default then depends on the preferred work-flow in
your project.

>  > > "Relative to a repo URL" *is* a namespace.
> 
>  > Exactly. No need for any naming convention, since a perfectly natural
>  > namespace already exists. Except that git allows to arbitrarily rename
>  > remote branches, circumventing "qualification" with the remote URL, so
>  > they look like local ones. This should not be allowed (IMHO).
> 
> This is how Subversion works (and CVS before it and Bazaar
> "lightweight checkouts" after it).  With that restriction, distributed
> development is painful.  Avoiding that restriction is why Arch,
> BitKeeper, git, Mercurial, Monotone, Bazaar, ... were developed.
> Darcs, too. :-)

I don't understand. What has distributed versus centralized to do with
it? I'd say in a centralized system there is only one "remote", so the
question is moot. Is that what you mean?

> Most people prefer working within that restriction to dealing with
> concurrency, I admit, but highly concurrent development is really
> painful with it.  

Re: [darcs-users] so long and thanks for all the darcs

[Stephen J. Turnbull]

Ben Franksen writes:

 > > The refs are supposed to all be copied to refs/remotes/origin,

 > Hm, that may clarify a few things for me. So a "ref" is a file which
 > contains a hash that references an object.

That's how it's made persistent.  However, there are older methods
(symlinks, for example) that you might find in very old repos, and
abstractly a ref is any pointer into the DAG.  There is also a ref
"algebra" for computing relative refs (eg, HEAD^ and HEAD~2) which is
very frequently used in commands.

 > The content of a ref is globally valid and thus can be (and is)
 > copied between repos, but the name of that file (including the
 > directory in which it is located) is a purely local property.
 > Correct?

Yes.

 > If yes, then I begin to understand why as a Darcs user I found it so
 > difficult to become familiar with git. Because this concept of a "ref"
 > has no (user visible) counterpart in Darcs. It doesn't exist because it
 > is not needed (for the user). We /could/ add something like it so we can
 > refer to patches symbolically, but AFAIK nobody has ever found it useful
 > enough to request it as a feature.

That sounds almost right to me.  The exception is a tag, which is
present in Darcs and induces a version via its dependencies, whereas
in a DAG-based VCS it is a ref, and points to a version in the history
graph.

 > Whereas in git the concept is essential because many of the high-level
 > features that make git usable as a tool for day-to-day work are built on
 > it.

In fact, any DAG-based VCS requires refs.  Mercurial and Bazaar add a
sequence number ref type (and in Bazaar it's actually a structured
sequence number which identifies the branch and version relative to
the branch point, recursively \o/).

 > The core of git is sound, simple, and elegant; but the high-level
 > features that build on it have been developed in an ad-hoc manner
 > without an over-arching and similarly elegant abstraction to guide the
 > design, so it remains necessary to understand the mechanism behind them
 > in order to use (and appreciate) them appropriately. I think /this/ is
 > the deeper reason behind git's "bad UI" reputation.

>From my point of view, all you've said is "people don't grok DAGs". :-)
For some reason nobody gets this, but git is just a Scheme for
managing version control.  (Mercurial is a Common Lisp, and Bazaar is
a Common Lisp with everything stuffed into tiny packages recursively).

 > > but only the currently checked out one at remote is linked to a local
 > > branch, and checked out locally. Configuration ("core" options in 
 > > .git/config) comes from your local template, I believe.

 > Okay. I would expect that all local branches are initially linked to
 > their remote counterpart.

This would be really ba-a-ad if you were working on the kernel where
everybody is cloning everybody else's repos all the time.  The git
developers all are kernel developers. ;-)

I would think "link 'em all" is a better default for most projects,
except that in git branch refs are really lightweight, so developers
are likely to have a bunch of obsolete or experimental branches lying
around that you don't want.  So except for really small projects with
very few developers, I think on balance I don't want link 'em all.
YMMV, of course, even with that caveat.

 > > "Relative to a repo URL" *is* a namespace.

 > Exactly. No need for any naming convention, since a perfectly natural
 > namespace already exists. Except that git allows to arbitrarily rename
 > remote branches, circumventing "qualification" with the remote URL, so
 > they look like local ones. This should not be allowed (IMHO).

This is how Subversion works (and CVS before it and Bazaar
"lightweight checkouts" after it).  With that restriction, distributed
development is painful.  Avoiding that restriction is why Arch,
BitKeeper, git, Mercurial, Monotone, Bazaar, ... were developed.
Darcs, too. :-)

Most people prefer working within that restriction to dealing with
concurrency, I admit, but highly concurrent development is really
painful with it.  These systems all force you to rebase all your work
on top of the official version before you can commit even once,
because when concurrent development is taking place, there are
multiple branches with the same name in this model: one local, one
official, and possibly others local to other developers (or even
yourself!)  Determining whether you are synched to official requires a
remote query with an irremediable race condition, and it's impossible
to know if you're synched with third party branches with that name.

Darcs avoids all this by modeling a branch as a history-less set of
patches.  Of course the semantics of text require certain implicit
dependencies (you can't delete a line that doesn't exist in the text).
Also of course you want semantic dependencies (don't add a patch
calling foo() in module bar if you don't have the patch that adds
module foo, for example).  History-based VCSes 

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Hi Steve

sorry for (again) responding at length. You gave me yet more ideas...

Am 22.03.2018 um 01:15 schrieb Stephen J. Turnbull:
> Ben Franksen writes:
>> My experience with git tells me that when I make a clone what I get
>> is /not/ identical to upstream.
> 
> I may have miswritten. What is identical is the object database.
Okay.

> The refs are supposed to all be copied to refs/remotes/origin,
Hm, that may clarify a few things for me. So a "ref" is a file which
contains a hash that references an object. The content of a ref is
globally valid and thus can be (and is) copied between repos, but the
name of that file (including the directory in which it is located) is a
purely local property. Correct?

If yes, then I begin to understand why as a Darcs user I found it so
difficult to become familiar with git. Because this concept of a "ref"
has no (user visible) counterpart in Darcs. It doesn't exist because it
is not needed (for the user). We /could/ add something like it so we can
refer to patches symbolically, but AFAIK nobody has ever found it useful
enough to request it as a feature.

Whereas in git the concept is essential because many of the high-level
features that make git usable as a tool for day-to-day work are built on
it. The core of git is sound, simple, and elegant; but the high-level
features that build on it have been developed in an ad-hoc manner
without an over-arching and similarly elegant abstraction to guide the
design, so it remains necessary to understand the mechanism behind them
in order to use (and appreciate) them appropriately. I think /this/ is
the deeper reason behind git's "bad UI" reputation.

> but only the currently checked out one at remote is linked to a local
> branch, and checked out locally. Configuration ("core" options in 
> .git/config) comes from your local template, I believe.
Okay. I would expect that all local branches are initially linked to
their remote counterpart.

>> And clones of a clone are definitely second class, at least not
>> out of the box.
> 
> If you want an identical clone of a clone, rsync is your friend. But 
> I don't know what you mean by "second class". (I'm curious; I don't 
> doubt that it fails to work as expected.)
Unfortunately I can't remember the details. It may be that I just failed
to understand how to setup the second clone appropriately. Because...
see above.

>>> You've already admitted that it's necessary because of name 
>>> collisions. You just don't like it. :-)
>> 
>> I did not admit anything like that. There are no name collisions
>> if branch names are always relative to a repo URL. No need for 
>> namespacing branches.
> 
> "Relative to a repo URL" *is* a namespace.
Exactly. No need for any naming convention, since a perfectly natural
namespace already exists. Except that git allows to arbitrarily rename
remote branches, circumventing "qualification" with the remote URL, so
they look like local ones. This should not be allowed (IMHO).

>>> People used to do things like name their tracking branches 
>>> -, but that had two disadvantages. One, many 
>>> people did what you seem to find natural, and omit the 
>>> "-" part. After all, it's not my branch, so I won't work 
>>> on it, right?
>> 
>> No, this is not what I find natural. What I find natural is that in
>> my clone the beasts have the same name as in the remote repo from
>> which I cloned, at least by default.
> 
> I don't understand.
You seem to associate branches with an owner ("it's not my branch"). An
interesting aspect I haven't considered yet. So there is a person at the
remote repo who controls (or likes to control) the history of this
branch. He or she is upset if I push a commit to this branch? I should
rather have created my own branch and committed there, so the remote
owner of the branch can integrate my changes with a merge?

> AIUI, that's exactly what I said was natural: many users set up the
> tracking branch as a normal branch with the same name as in the
> source repo.
This would be perfectly okay /if/ this name could never be confused with
a remote branch of the same name, which would require that it is
impossible to give a remote branch a "plain", unqualified name.

>>> Turns out that for various reasons people *do* unintentially 
>>> commit to those branches.
>> 
>> So what? I don't see how this is a problem.
> 
> You don't see how anyone would commit to a branch they didn't intend 
> to, or you don't see how unintentional commits are a problem?
I don't see how a commit can be problematic even if it was made
unintentional. You commit explicitly by issuing a command, presumable
after making some changes. This creates a new version (commit object).
If this was indeed unintentional, what's the problem?

However, I see that if you accidentally push these changes, this can be
problematic (if you do not "own" the branch). Because apparently in git
if you push, then the remote branch ref is updated to where it points to
locally. Right?

(Sigh. Push 

Re: [darcs-users] so long and thanks for all the darcs

[Wolfgang Jeltsch]

Am Donnerstag, den 22.03.2018, 09:12 +0900 schrieb Stephen J. Turnbull:
> Wolfgang Jeltsch writes:
> 
> > What about double-clicks, which mark the word (in this case, the 
> > SHA1 hash) under the cursor?
> 
> The discoverability problem (git repositories normally will have
> several dangling heads, and if rebase is used, there would be many)
> still means that real people (as opposed to discussants in mailing
> list threads) are going to want mnemonic aliases.  Since the mental
> model is that the local branch is synchronized (and up to date) with
> some remote branch, the name used in the remote repo will be strongly
> preferred.


> Might be true, but I was just referring to your argument that marking
> SHA1 hashes is error-prone.

All the best,
Wolfgang
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Benjamin Franksen]

On 03/20/2018 10:33 AM, Stephen J. Turnbull wrote:
[about git's message "you are in 'detached HEAD' state..."]
>  > > But to get that message you need to explicitly checkout a commit that
>  > > is not the target of a branch ref. 
>  > 
>  > A tag, for instance.
> 
> Yes.  I guess that a lot of people would prefer that git add a bunch
> of implementation complexity so that it would warn when changing
> branches away from a detached HEAD, and only if there were commits to
> that branch or trying to push.
I just got that 'detached HEAD' message again and must admit that git
does the right thing here. It does not complain at all but warns me that
new commits may be lost and also tells me how to create a branch to
retain them. Pretty nice actually.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 20.03.2018 um 10:33 schrieb Stephen J. Turnbull:
> Ben Franksen writes:
>  > Am 19.03.2018 um 09:12 schrieb Stephen J. Turnbull:
>  > But git chooses to not clone all the refs by default and there is a
>  > reason for that because it would have to pull all the referenced
>  > commits, too,
> 
> As far as I know, git clones the whole object database and sets up one
> tracking branch (which one depends on the checked-out branch in the
> source).  Optionally you can restrict to a single branch by explicitly
> specifying the --single-branch option.  It also copies all refs to
> $GITDIR/refs/remotes/origin, so in fact you have the whole state of
> the cloned repo at the time of cloning.

I was merely paraphrasing what you said earlier:

> I don't think this is possible with raw git on a remote repository.  I
> believe you need to fetch all the remote refs, and query locally.

and trying to find a good reason why this would be the case.

My experience with git tells me that when I make a clone what I get is
/not/ identical to upstream. Instead I get something that is supposed to
be used as a downstream working copy, similarly to how with Subversion
and CVS one works on a "checkout" of the central repository. And clones
of a clone are definitely second class, at least not out of the box. I
know all these problems can be worked around if you know the right
magical incantations but I keep forgetting them because they are so
abstruse.

>  > > So the solution the git developers came up with was providing
>  > > namespaces (called "remotes" in git documentation) so that one
>  > > name could refer to several heads at the same time.
>  > 
>  > This is what I mean. Even following mentally what you wrote here gives
>  > me headaches. Not because of its complexity per se, but because of
>  > *unnecessary* complexity.
> 
> You've already admitted that it's necessary because of name
> collisions.  You just don't like it. :-)

I did not admit anything like that. There are no name collisions if
branch names are always relative to a repo URL. No need for namespacing
branches.

>  > Yeah, discourage the feature, but first add it because it's oh so
>  > cool and cheap, making everyone's live difficult because they now
>  > all have to cope with the resulting complexity.
> 
> I think you misunderstand how git works.

Probably, but I am trying, and I am not stupid (except sometimes).

>  These are just refs, tiny
> files that contain one SHA1 terminated with a newline character, no
> more and no less.

What I said: cheap.

>  People used to do things like name their tracking
> branches -, but that had two disadvantages.  One, many
> people did what you seem to find natural, and omit the "-" part.
> After all, it's not my branch, so I won't work on it, right?

No, this is not what I find natural. What I find natural is that in my
clone the beasts have the same name as in the remote repo from which I
cloned, at least by default.

>  Turns
> out that for various reasons people *do* unintentially commit to those
> branches.

So what? I don't see how this is a problem.

>  Second, whatever the name, you don't want to commit to
> those branches,

Why not?

> so having them in the default namespace is pollution.

Exactly what I was saying: they started with a cheap and harmless
looking feature and then had to introduce lots of complexity to deal
with the consequences.

> The solution is elegant, IMO: move refs to tracking branches to a
> standard (and quite arbitrary) place, and teach the functions that
> have need to know (config, fetch, and push) where that is.
> Furthermore, since they're not in refs/heads anymore, git refuses to
> treat them as branches (checking out a remote ref puts you in
> "detached HEAD" mode).  IOW, since they're just files (and not R/O),
> you can edit them.  But the only way git will change them is on a
> successful fetch or push, to synchronize to the remote.

I guess we'll have to agree to disagree on this point.

>  > > But to get that message you need to explicitly checkout a commit that
>  > > is not the target of a branch ref. 
>  > 
>  > A tag, for instance.
> 
> Yes.  I guess that a lot of people would prefer that git add a bunch
> of implementation complexity so that it would warn when changing
> branches away from a detached HEAD, and only if there were commits to
> that branch or trying to push.  

I am not one of them.

>  > Copy & paste? It's 2018, not the 1970s.
> 
> I frequently drop characters at the beginning or end of a selection
> when using touchpads or handhelds, and occasionally with a mouse.
> Unfortunately git accepts prefixes  SHA1s are also less than
> mnemonic (at least if your name is not Ramanujan!) -- how do you know
> you've got the right one when you can't query the remote for SHA1
> equivalents to branch refs?  Without the refs, all you would have is a
> bag of dangling heads among all your dangling heads from rebases etc.

I am not against refs but against remotes and 

Re: [darcs-users] so long and thanks for all the darcs

[Wolfgang Jeltsch]

Am Dienstag, den 20.03.2018, 18:33 +0900 schrieb Stephen J. Turnbull:
> Ben Franksen writes:
> > Copy & paste? It's 2018, not the 1970s.
> 
> I frequently drop characters at the beginning or end of a selection
> when using touchpads or handhelds, and occasionally with a mouse.

What about double-clicks, which mark the word (in this case, the SHA1
hash) under the cursor?

All the best,
Wolfgang
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Stephen J. Turnbull]

Ben Franksen writes:
 > Am 19.03.2018 um 09:12 schrieb Stephen J. Turnbull:

 > > I don't think this is possible with raw git on a remote repository.  I
 > > believe you need to fetch all the remote refs, and query locally.
 > 
 > In Darcs we have to query the remote repo anyway. You don't want to
 > transfer patches that are already present at the other end. I am sure
 > git has a way to avoid sending commits that the remote already has.

Of course it does.  What I meant is that there's no way for the user
to do this.

 > But git chooses to not clone all the refs by default and there is a
 > reason for that because it would have to pull all the referenced
 > commits, too,

As far as I know, git clones the whole object database and sets up one
tracking branch (which one depends on the checked-out branch in the
source).  Optionally you can restrict to a single branch by explicitly
specifying the --single-branch option.  It also copies all refs to
$GITDIR/refs/remotes/origin, so in fact you have the whole state of
the cloned repo at the time of cloning.

 > and that is costly. Not so in Darcs.

I don't see a big difference.  There's a bit of CPU involved, but a
git pack (used both for disk storage and for network transfers) is
basically a diff-compressed archive, just as it would be in Darcs.  In
practice, few branches in git get very long, or involve a lot of
difference.  Unless you mean that Darcs doesn't really support
multiple branches in a repository so it's no problem?

 > > So the solution the git developers came up with was providing
 > > namespaces (called "remotes" in git documentation) so that one
 > > name could refer to several heads at the same time.
 > 
 > This is what I mean. Even following mentally what you wrote here gives
 > me headaches. Not because of its complexity per se, but because of
 > *unnecessary* complexity.

You've already admitted that it's necessary because of name
collisions.  You just don't like it. :-)

 > Yeah, discourage the feature, but first add it because it's oh so
 > cool and cheap, making everyone's live difficult because they now
 > all have to cope with the resulting complexity.

I think you misunderstand how git works.  These are just refs, tiny
files that contain one SHA1 terminated with a newline character, no
more and no less.  People used to do things like name their tracking
branches -, but that had two disadvantages.  One, many
people did what you seem to find natural, and omit the "-" part.
After all, it's not my branch, so I won't work on it, right?  Turns
out that for various reasons people *do* unintentially commit to those
branches.  Second, whatever the name, you don't want to commit to
those branches, so having them in the default namespace is pollution.

The solution is elegant, IMO: move refs to tracking branches to a
standard (and quite arbitrary) place, and teach the functions that
have need to know (config, fetch, and push) where that is.
Furthermore, since they're not in refs/heads anymore, git refuses to
treat them as branches (checking out a remote ref puts you in
"detached HEAD" mode).  IOW, since they're just files (and not R/O),
you can edit them.  But the only way git will change them is on a
successful fetch or push, to synchronize to the remote.

 > > But to get that message you need to explicitly checkout a commit that
 > > is not the target of a branch ref. 
 > 
 > A tag, for instance.

Yes.  I guess that a lot of people would prefer that git add a bunch
of implementation complexity so that it would warn when changing
branches away from a detached HEAD, and only if there were commits to
that branch or trying to push.  

 > Copy & paste? It's 2018, not the 1970s.

I frequently drop characters at the beginning or end of a selection
when using touchpads or handhelds, and occasionally with a mouse.
Unfortunately git accepts prefixes  SHA1s are also less than
mnemonic (at least if your name is not Ramanujan!) -- how do you know
you've got the right one when you can't query the remote for SHA1
equivalents to branch refs?  Without the refs, all you would have is a
bag of dangling heads among all your dangling heads from rebases etc.

 > > The nagging [about multiple heads] matters, though. ;-)
 > 
 > In practice it does, yes. I meant that the "kernel" has no problems
 > with it.

No, but users do.  It's frequently not obvious to me which head is
tip, and at least before my habits formed I found myself "twisting"
the mainline, which annoyed some coworkers (most those who wished they
were using Bazaar).

 > > As I understand it, the patch knows about its dependencies, right?
 > 
 > Only the explicit ones. The implicit dependencies are, well,
 > implicit.

Ouch, see below.

 > > So if you've been diligent about recording semantic dependencies,
 > > you should be able to reconstruct the feature the patch helps
 > > implement.
 > > 
 > > Do I have that right?
 > 
 > Yes, I think so.

But apparently requires a bit more luck than I estimated. 

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 05.03.2018 um 04:40 schrieb Stephen J. Turnbull:
> Executive summary:
> 
> Darcs is an elegant system with a very simple underlying repository
> model (set of patches) and an implementation that is faithful to that
> model.  This makes Darcs easy to understand and use.
> 
> Although git and Mercurial (and Bazaar) share a repository model that
> is somewhat more complex (DAG of versions), only git's implementation
> is faithful with an immutable representation of history.  Mercurial's
> and Bazaar's implementations violate faithfulness and immutability, so
> their designers chose to restrict the operations available for safety
> and simplicity.

Do you have any references supporting this assertion? It is the first
time I have seen it made and are somewhat perplexed (and intrigued).

(edit: you do explain most of it below)

>  Paradoxically, perhaps, I believe this is why git
> dominates the revision control landscape today despite its widely
> reviled UI.

An interesting thought.

>  (I very briefly address the social process that led to
> this outcome.)
> 
> I have two questions about current darcs:
> 
> 1.  How do people handle configuration management?  Just keep separate
> repos for every configuration of the software to be distributed?

Yes, more or less. For small differences I sometimes make a patch with a
'LOCAL DONT PUSH configuration adapted bla bla' prefix and keep it in
the same repo. Such a patch usually commutes with the vast majority of
the development patches, but you have to be careful not to push it by
accident.

It would be nice if I could tag such patches more explicitly as "don't
push this when pushing (and don't pull when being pulled)", at least by
default (i.e. overridable with a switch). You can emulate this by
keeping a copy of the repo with this patch and using --intersection
 when pushing but that is awkward to use.

> 2.  What features or extensions for forensic work (localization) are
> available for Darcs?  I'm thinking about features like bisect commands
> (common in DAG-based systems) and git's "pickaxe".

We have the 'darcs test' command. I believe it is similar to git's
bisect, see 'darcs test --help' for details. I don't use it often
because usually I am faster (less unneeded compilation time) with the
manual process (obliterate in big chunks, run test, repeat until
successful, pull in somewhat smaller chunks, etc). If you go far enough
back in time, compilation can fail due to changes in build-dependencies
or the tool chain and such problems require manual interaction anyway.

> On to the tl;dr part.  I ended up having to work through a lot of
> stuff to figure out what I think about the various VCSes, and record
> it here for those interested in understanding why git seems so wrong-
> headed to many users, and yet persists in its idiosyncratic ways.  I'm
> sure there will be many points of disagreement, but I hope it will be
> useful.
> 
> Ben Franksen writes:
>  > Am 04.03.2018 um 05:03 schrieb Karl O. Pinc:
> 
>  > > It's not that the command line interface is more sensible.  It's
>  > > that the mental model of a repo with which the mercurial commands
>  > > interact is simple.
> 
> Unfortunately, that just doesn't hold up.  Mercurial repos are subject
> to a whole bunch of constraints that you need to understand to deal
> with its edge cases or to extend its operations.  And some of it is
> just plain ugly (tags are commits, for example).

I found this out the hard way. If you clone a tag you don't get the
patch that sets the tag, so you are one patch behind. This is just
idiotic (IMHO) and should be fixed.

In darcs tags are also just patches, but if you pull a tag you get the
tag itself, too (since this is how it works: a tag artificially depends
on all patches present when you create it).

>  It's DAG-based, but
> there's a lot of other crap there.  A *correct* mental model of git is
> extremely simple, almost as simple as Darcs.  (Hint: without merges,
> it's just a singly-linked list, like the fundamental structure in
> Lisp.)  The problem with git is that people like to reify branches (cf
> Stephane's comments about branch-per-repo, also Mercurial's named
> branch misfeature), and that is incompatible with what actually
> happens in git, where a "branch" is just a name for the head of a
> chain of commits.  git does *nothing* to cater to this natural
> instinct.

I must say I don't really understand what you are saying. What does
"people like to reify branches" mean, exactly?

If you have a DAG "without merges" then it becomes a (inverted) tree and
every leaf has a unique path from the root to it, a singly-linked list
if you prefer. This should be true whenever you have a DAG of revisions.

> It's very hard to get Darcs' "set of patches" model wrong.  I think
> that's part of the appeal of Darcs.

The "set of patches" model can be misleading. Nowadays I tend to explain
darcs to people in terms of a single sequence of patches, some of which
can be and will 

Re: [darcs-users] so long and thanks for all the darcs

[Evan Laforge]

On Mon, Mar 5, 2018 at 2:08 AM, Ben Franksen  wrote:
> I have just tried this and in fact when I resume the edit all the escape
> sequences are printed literally. However, the editor does react to them:
> I can quit using ":q" and the garbage on the screen isn't actually put
> in the log. Still a bug which I intend to fix, see
> http://bugs.darcs.net/issue2572.

Good deal.  I know these kinds of weird terminal interaction bugs are
not necessarily easy or fun to track down, but it's one of those
usability details that no one notices when it works and everyone
complains when it doesn't :)
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 05.03.2018 um 10:19 schrieb Ben Franksen:
> Am 05.03.2018 um 03:40 schrieb Evan Laforge:
>> Record changes in darcs 2.12.5, then say yes to "add a long comment"
>> where EDITOR=vim.  Now ^Z out of vim, and then fg back.  At that
>> point, vim is in command mode, but any keys just appear literally on
>> the screen, so there's no way to save or quit or do anything.  The
>> only way out is to kill vim from another terminal, at which point
>> darcs finishes the record (I guess it doesn't mind that vim return
>> nonzero?).

I have just tried this and in fact when I resume the edit all the escape
sequences are printed literally. However, the editor does react to them:
I can quit using ":q" and the garbage on the screen isn't actually put
in the log. Still a bug which I intend to fix, see
http://bugs.darcs.net/issue2572.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Evan Laforge]

On Mon, Mar 5, 2018 at 1:19 AM, Ben Franksen  wrote:
> But you /can/ work in the same way with darcs: just don't (q)uit, rather
> say (d)one. Then use 'darcs amend' to add more changes or 'darcs amend
> --unrecord' to remove changes. There is also the --edit-long-comment
> option for amend.

Yes, I also often worked this way.  I don't know why I didn't use it
more than I did though... maybe because of:

> We could improve the workflow a bit by presenting the changes in the
> opposite order with 'amend --unrecord', so it acts more like an undo.

Yes, I have definitely wanted exactly this feature more than once.
I'm all for it.
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 05.03.2018 um 01:47 schrieb Karl O. Pinc:
> On Sun, 4 Mar 2018 23:23:33 +0100
> Ben Franksen  wrote:
> 
>> What made me re-consider
>> the idea was that I found I like the way mercurial automatically
>> creates a branch when you pull a conflicting patch.
> 
>> But
>> when you look at it from a darcs viewpoint, automatically creating a
>> branch really makes sense only if there is no "clean" merge, that is
>> if there is a conflict; otherwise you just pull patches and that's it.
> 
> FYI.  I regularly pull with --no-allow-conflicts.

Me too. I have this set in my ~/.darcs/defaults ever since rebase came out.

>> In contrast, branches are fully symmetric: none is better
>> than the other, patch identities remain unmodified, and you can
>> switch between them easily.
> 
> Would be nice to be able to assume that the remote repo 
> is not "better".

Yes.

>> These are all pretty raw ideas at the moment, none of it is
>> implemented. There are lots of open questions regarding UI design etc.
> 
> I know a lot of thought gets done on IRC 

I am mostly using the lists and the bug/patch tracker. However, most of
it is on the darcs-devel list, partly because all changes and comments
in the tracker are auto-forwarded as emails to the devel list.

> but as far as UI
> goes it might be good to run thoughts by this mailing list.

Yes, UI and design of new features should be discussed here in public
where some of our users hang out. Will try to remember. If it starts out
via tracker, we should add darcs-users to the nosy list. This may spam
you with technical details every now and then but I guess that's acceptable.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 05.03.2018 um 03:40 schrieb Evan Laforge:
> On Sun, Mar 4, 2018 at 2:46 AM, Ben Franksen  wrote:
>>> There are a few other quibbles, like how obliterate -O is too slow to
>>> be useful,
>>
>> (perhaps we should have made --no-minimize the default?)
> 
> Is that what you get when you ^C while it's working?  If so, yeah I'd
> optimize for speed over disk usage.

Perfectly reasonable, that's what ~/.darcs/defaults is for.

However, disk usage wasn't the motivation for minimizing the context.
Instead, the main motivation was to increase the chance that the bundle
can be applied even if some of its original context is missing. If your
patch history is [A,B,C] and C is obliterated with -O --no-minimize,
then the context is [A, B] and the bundle cannot be applied to [A], even
if C does not depend on B. You could work around that by manually
editing the context in the bundle (it's a plain text file) which I did
several times in the past before I opened a ticket for this feature and
someone else implemented it.

>>> conflict markers don't label their sections, ^Z out of
>>> editing a commit message can badly hose the terminal,
>>
>> I guess that is on Windows (it would be ^D or rather ^C on Linux and it
>> works there). Our Windows support is lacking, sadly, mostly because I
>> have not yet managed to set up an environment where I can build and test
>> on Windows.
> 
> Actually it's xterm on linux.  I *think* I saw it on iterm2 on OS X as
> well.  It doesn't happen with 2.10.1, and does with 2.12.5.

Okay, I misunderstood. You suspend the editor with ^Z.

> My guess it that it has to do with how darcs prompts put the terminal
> into raw mode, then vim of course uses raw mode, somehow the state
> saving and restoring gets messed up when you ^Z out and fg back in.
> It's easy for me to reproduce:
> 
> Record changes in darcs 2.12.5, then say yes to "add a long comment"
> where EDITOR=vim.  Now ^Z out of vim, and then fg back.  At that
> point, vim is in command mode, but any keys just appear literally on
> the screen, so there's no way to save or quit or do anything.  The
> only way out is to kill vim from another terminal, at which point
> darcs finishes the record (I guess it doesn't mind that vim return
> nonzero?).

Thanks for clarifying. I will open a ticket and perhaps try to fix that one.

> I also looked into pijul, but at the time the log command was broken
> and it made me think if they're still at the state where basic
> commands just don't work at all sometimes and no one notices then it's
> not yet ready to trust with a real project.  I wish them luck too.

Me too, i think the idea is great, but - as always - the devil is in the
details.

> WRT branches, I too like the simplicity of them just being separate
> repos.  Maybe this just needs a wrapper command that understands the
> tree structure of the various branches, and then can do higher level
> operations across branches like pull or push them all, or visualize
> where they are, or whatever.  At least for me making the whole thing
> feel lighter weight would go a long way, even if it's really the same
> underneath.  

See my reply to Karl on this thread. Let me add that adding in-repo
branches would not be a big change in the underlying structure. Quite
the opposite, as I recently realized we have everything we need already
in place.

Patches are organized in what we call "inventories". These are files
that record which patches are applied in which order. Inventories are
stacked: when you tag a repo the current inventory is closed and a new
one is opened, starting with a reference to the old one.

So an in-repo branch is simply another top-level inventory. All we need
to add is a new directory _darcs/branches to store the currently
inactive branches (=inventories). (Now, as I write this down, i also
realize that we probably want to store pristine trees for each branch,
so that switching between repos will be fast.)

> The other thing would be making it all faster, maybe it
> could be lazy by default or have some way to get a COW copy without
> having to copy or hardlink a zillion patch files.  I guess the global
> cache is already doing that, but it's still not sub-second, and it
> seems to grow with repo size.

Yes to all you said here.

I guess we should really bundle all patches beyond the most recent tag
into one big file by default. It is pretty uncommon to work with patches
behind a tag.

> The idea of splitting the branch on a conflict is very interesting.
> Sometimes it seems awkward to back out if I pull a conflicting patch,
> so any pull can be scary.  I guess it's because the conflict detritus
> gets mixed in with uncommitted local changes.  I would not be scared
> if I knew that I could just delete the branch to back out.  Branching
> history rather than mutating the present should be a familiar concept
> to Haskell programmers :)

Yes!

> Also, I know this is external tool territory, but there really needs
> 

Re: [darcs-users] so long and thanks for all the darcs

[Evan Laforge]

On Sun, Mar 4, 2018 at 2:46 AM, Ben Franksen  wrote:
>> There are a few other quibbles, like how obliterate -O is too slow to
>> be useful,
>
> (perhaps we should have made --no-minimize the default?)

Is that what you get when you ^C while it's working?  If so, yeah I'd
optimize for speed over disk usage.

>> conflict markers don't label their sections, ^Z out of
>> editing a commit message can badly hose the terminal,
>
> I guess that is on Windows (it would be ^D or rather ^C on Linux and it
> works there). Our Windows support is lacking, sadly, mostly because I
> have not yet managed to set up an environment where I can build and test
> on Windows.

Actually it's xterm on linux.  I *think* I saw it on iterm2 on OS X as
well.  It doesn't happen with 2.10.1, and does with 2.12.5.

My guess it that it has to do with how darcs prompts put the terminal
into raw mode, then vim of course uses raw mode, somehow the state
saving and restoring gets messed up when you ^Z out and fg back in.
It's easy for me to reproduce:

Record changes in darcs 2.12.5, then say yes to "add a long comment"
where EDITOR=vim.  Now ^Z out of vim, and then fg back.  At that
point, vim is in command mode, but any keys just appear literally on
the screen, so there's no way to save or quit or do anything.  The
only way out is to kill vim from another terminal, at which point
darcs finishes the record (I guess it doesn't mind that vim return
nonzero?).

>> and you need an
>> obscure DARCS_DONT_ESCAPE_8BIT to show utf8 properly, but any complex
>> tool has its share of those kind of things.
>
> True. Just to mention it, I fixed this particular problem some time ago
> (not yet released, partly because it doesn't yet work on Windows as well
> as on Linux, see below).

Glad to hear :)

>> And then of course that it's
>> increasingly non-mainstream compared to git + github or gitlab, and
>> probably causes people to think twice before getting involved.  I
>> dislike a monoculture too but you can only die on so many hills at
>> once :)
>
> ;-) I have chosen to die on this one and don't expect many others to
> stay at my side... and I do need a somewhat longer break every now and then.

I'm glad someone is doing it, the commutative patch approach is quite
nice and it should be developed.

I also looked into pijul, but at the time the log command was broken
and it made me think if they're still at the state where basic
commands just don't work at all sometimes and no one notices then it's
not yet ready to trust with a real project.  I wish them luck too.

WRT branches, I too like the simplicity of them just being separate
repos.  Maybe this just needs a wrapper command that understands the
tree structure of the various branches, and then can do higher level
operations across branches like pull or push them all, or visualize
where they are, or whatever.  At least for me making the whole thing
feel lighter weight would go a long way, even if it's really the same
underneath.  The other thing would be making it all faster, maybe it
could be lazy by default or have some way to get a COW copy without
having to copy or hardlink a zillion patch files.  I guess the global
cache is already doing that, but it's still not sub-second, and it
seems to grow with repo size.

The idea of splitting the branch on a conflict is very interesting.
Sometimes it seems awkward to back out if I pull a conflicting patch,
so any pull can be scary.  I guess it's because the conflict detritus
gets mixed in with uncommitted local changes.  I would not be scared
if I knew that I could just delete the branch to back out.  Branching
history rather than mutating the present should be a familiar concept
to Haskell programmers :)

Also, I know this is external tool territory, but there really needs
to be some nicer way to merge than looking for 'v's and trying to
figure out what all those *s and =s mean and what happened and what
changed.  Even just documentation examples of how to integrate with a
3-way merge tool could help a lot.

While I'm at the wishing well it would be nice if interactive record
could save its state so you don't have to redo it all if you quit out
of it.  This could get the effect of git's staged commit but without
the complicated "cache" layer, just a file with the record state that
you can use to resume if you want.  I know I've whinged about this
before, but it *is* nice how in git I can do add -p, then quit, make
some more changes, add some more hunks, etc. and commit at the end.
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Karl O. Pinc]

On Sun, 4 Mar 2018 23:23:33 +0100
Ben Franksen  wrote:

> What made me re-consider
> the idea was that I found I like the way mercurial automatically
> creates a branch when you pull a conflicting patch.

> But
> when you look at it from a darcs viewpoint, automatically creating a
> branch really makes sense only if there is no "clean" merge, that is
> if there is a conflict; otherwise you just pull patches and that's it.

FYI.  I regularly pull with --no-allow-conflicts.

> In any case
> you'd rather want to avoid doing conflict resolution when you are in
> the middle of finishing something else.

Agreed.

> In contrast, branches are fully symmetric: none is better
> than the other, patch identities remain unmodified, and you can
> switch between them easily.

Would be nice to be able to assume that the remote repo 
is not "better".

> 
> Branches would also allow us to do many of the "destructive"
> operations less dangerously by default.

Does sound appealing.

> These are all pretty raw ideas at the moment, none of it is
> implemented. There are lots of open questions regarding UI design etc.

I know a lot of thought gets done on IRC but as far as UI
goes it might be good to run thoughts by this mailing list.

Up to you.

Regards, and thanks for all the work!

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 04.03.2018 um 21:12 schrieb Karl O. Pinc:
> On Sun, 4 Mar 2018 12:04:01 +0100
> Stephane Bortzmeyer  wrote:
> 
>> * no branches. Don't add them! The one-branch-per-repo model is much
>> better
> 
> Thinking out loud here.
> 
> If I had to vote today I'd say:
> 
>   -1 on branches in the default darcs
> 
>   Perhaps being able to point to various repos in the
>   darcs configuration and call them "branches" might be
>   cool.  But come to think of it it's probably better
>   to just call them repositories and add options to,
>   say, the diff sub-command to be able to handle
>   other repositories.  Maybe provide some short-hand for
>   repo naming and call that short-hand label a "branch"
>   name.  Seems like checking out a "branch" is just
>   switching your defaultrepo.  
> 
>   Anyway, adding what
>   amounts to a lot of syntatic sugar into the default
>   darcs does not appeal.  One way to do something is always
>   less confusing than many ways to do the same thing.

I was always thinking along similar lines. What made me re-consider the
idea was that I found I like the way mercurial automatically creates a
branch when you pull a conflicting patch. Of course, a mercurial user
would correct me at this point: it doesn't matter if the patch conflicts
or not, it's just that the histories diverge. But when you look at it
from a darcs viewpoint, automatically creating a branch really makes
sense only if there is no "clean" merge, that is if there is a conflict;
otherwise you just pull patches and that's it.

So I thought: what if darcs did /not/ by default create conflictors, and
instead puts the conflicting patch on a newly created branch? This would
give me the choice to /postpone/ what to do: I don't have to resolve
conflicts immediately but can do it at my leisure. Or perhaps I decide I
don't want to allow the conflict after all and rather rebase my local
changes. Or do a mixture of both. In any case you'd rather want to avoid
doing conflict resolution when you are in the middle of finishing
something else.

The automatic branch creation when pulling conflicting patches is a bit
like what 'darcs rebase pull' does but with an important difference:
suspending a patch commits yourself to changing its identity; local
patches that become suspended aren't first class patches any more: you
cannot switch to the "suspended patches branch". In contrast, branches
are fully symmetric: none is better than the other, patch identities
remain unmodified, and you can switch between them easily.

Branches would also allow us to do many of the "destructive" operations
less dangerously by default. For instance, darcs could create a branch
when you amend a patch: the old version of the patch simply lives on in
its own branch. If you later find the amend was a mistake, easy, just
switch to the other branch. Similarly for obliterate, and BTW much
easier to work with than obliterate -O which has a tendency of slowly
filling up your top directory with patch bundles. This would also allow
us to re-implement unrevert in a cleaner way: during a revert we just
gather all the changes into a new patch and afterwards put it in its own
branch. Unrevert can now choose between any number of unrevert-branches
and you no longer will be asked "warning: this will make unrevert
impossible, proceed?".

These are all pretty raw ideas at the moment, none of it is implemented.
There are lots of open questions regarding UI design etc.

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Stephane Bortzmeyer]

On Sat, Mar 03, 2018 at 05:54:48PM -0800,
 Evan Laforge  wrote 
 a message of 45 lines which said:

> I recently switched my main project from darcs to git.
> 
> I'm mentioning it because I feel like it might be one of the larger
> and older darcs repos out there, with the exception of darcs itself
> (10 years, 6328 patches, around 140k lines of haskell).

I still use darcs although, as soon as the project involves other
users, I have to use git.

My biggest darcs repository is 13 years old, 4166 files, 15262 patches. 

Things I like with darcs:

* no branches. Don't add them! The one-branch-per-repo model is much
better

* ease of cherry picking when committing. Generally speaking, ease of
use.

Things I don't like in darcs:

* slowness. Really painful some times, specially during network access
(a lot of chattering)

* no equivalent of gitlab




___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Ben Franksen]

Am 04.03.2018 um 05:03 schrieb Karl O. Pinc:
> On Sat, 3 Mar 2018 18:36:32 -0800
> Evan Laforge  wrote:
> 
>> On Sat, Mar 3, 2018 at 6:26 PM, Karl O. Pinc  wrote:
>>> This being so, I'm curious why a darcs user would choose
>>> git over mercurial.  
>>
>> Honestly, because I don't know mercurial.  I should fix that someday.
>> My impression is that it's like git but with a more sensible command
>> line interface, and has an elaborate plugin system with tons of
>> extensions (which nice in a way but scary in another way).
> 
> It's not that the command line interface is more sensible.  It's
> that the mental model of a repo with which the mercurial commands
> interact is simple.  _Almost_ as simple as darcs.  And almost
> the same as darcs.  I think the difference is that file name
> changes are essentially deletes and adds in mercurial.

There are much more fundamental differences in the model. Darcs is the
only tool I know of that can automatically re-order changes without
changing patch identities. Patches that don't depend on each other are
freely commuted whenever necessary or, in certain situations, at the
user's behest.

I agree with Evan that mercurial's UI is much more sensible than git's
and that their mental models are pretty similar. One thing that makes
git unnecessarily complicated to use IMO is the very loose coupling of
local and remote branches. I have never understood this design decision
and see absolutely no sensible use case for giving local branches a
different name than the remote ones or let the user change which local
branch is tracking which remote branch. Mercurial's main fault (IMO) is
that it does not support editing history natively. To do such
operations, one is forced to use low-level extensions like mq that
convert changes between revisions into dumb patch files (the stuff you
get with diff -u).

Cheers
Ben

___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Karl O. Pinc]

On Sat, 3 Mar 2018 18:36:32 -0800
Evan Laforge  wrote:

> On Sat, Mar 3, 2018 at 6:26 PM, Karl O. Pinc  wrote:
> > This being so, I'm curious why a darcs user would choose
> > git over mercurial.  
> 
> Honestly, because I don't know mercurial.  I should fix that someday.
> My impression is that it's like git but with a more sensible command
> line interface, and has an elaborate plugin system with tons of
> extensions (which nice in a way but scary in another way).

It's not that the command line interface is more sensible.  It's
that the mental model of a repo with which the mercurial commands
interact is simple.  _Almost_ as simple as darcs.  And almost
the same as darcs.  I think the difference is that file name
changes are essentially deletes and adds in mercurial.

> Is there a document for mercurial from the perspective of darcs out
> there?

Dunno.  My head's not in revision control space right now but
what I recall is that you use "hg" instead of "darcs",
"commit" instead of "record", and "status" instead of
"whatsnew -l".  Then if you want to do anything "extra",
like rebase you look on the hg website for help, or IRC,
and turn on the extension.

I have the following hg extensions enabled:

 histedit  interactive history editing
 rebasecommand to move sets of revisions to a different ancestor
 shelvesave and restore changes to the working directory
   ("git stash" equivalent)
 strip strip changesets and their descendants from history

The mental model for hg is very like that of darcs.
In the time you spend figuring out how to get
git to show a diff of what's going to be committed
(the key idea being that --cached uses the "index",
which is where your next commit is "staged")
you should be able to use hg to do most all of
everything you'll ever need it to do.

Helpful commands are:

  hg help extensions
  hg help revisions
  hg help revsets

and possibly

  hg help phases
  hg help glossary

hg log --graph is like gitk.

That's about all I can recall, other than the hg website
is helpful.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users

Re: [darcs-users] so long and thanks for all the darcs

[Evan Laforge]

On Sat, Mar 3, 2018 at 6:26 PM, Karl O. Pinc  wrote:
> I use darcs, git, and mercurial; git only
> for non-technical reasons.  I'm pretty much on-board
> with the git critique of:
> https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

Can't say I disagree much with that either :)

> This being so, I'm curious why a darcs user would choose
> git over mercurial.

Honestly, because I don't know mercurial.  I should fix that someday.
My impression is that it's like git but with a more sensible command
line interface, and has an elaborate plugin system with tons of
extensions (which nice in a way but scary in another way).

Is there a document for mercurial from the perspective of darcs out there?
___
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users