On 4/23/2011 11:55, Orchid XP v8 wrote:
>> If your change added the line ABC, isn't darcs diff going to
>> tell you you removed ABC from the WD?
>
> I'm not precisely sure what you're asking.

If I bring my WD up to date, then I fetch changes, then say "record", isn't 
that going to record a diff that backs out all your changes?

>> So what do you mean "apply"? What happens if your WD matches the
>> repository, then you do a fetch, then you say "record", what does Darcs do?
>
> Records a new patch reverting all the changes that you didn't apply,
> presumably.

That sounds really dangerous to me.

>>> It's the fact that you have to commit the merged version of the file as a
>>> new version. Every time you merge in a new change, you have to commit
>>> a new version. It just seems clunky and unecessary.
>>
>> It's mildly clunky, but it tells you which changes are applied to which
>> snapshots. git does this because it records files, not changes, yes.
>> It's probably the part of git that people like least.
>
> It's the part I least like, at any rate.

The tool that shows history has options to leave out commits that are 
nothing but merges without any other changes. :-)

>> What happens if I have a number of tags in the repository (v1 and v2 and
>> the current v3 under development), and I want to apply a bugfix to the
>> v1 version that doesn't apply to the later versions? How do I do that?
>
> You can't really use tags for that; you'd have to have seperate repos for
> v1, v2 and v3. Oh, you *can* put all the patches in one repo, but it's going
> to get messy very quickly.

See, git has no trouble with that. One repo has all of every version of 
Linux since 2.6.16 or so.

>> I might want the development branch to apply the changes but not the
>> branch that's half way thru QA testing.
>
> The Darcs way to do this is to store copies that are meant to be different
> in different places - which seems fairly logical to me. (Admittedly a little
> inefficient on disk space...)

And a bit fragile. The idea of git is that you have a repo with all the 
history in it. You don't have to chop it into multiple repos in order to 
actually exclude some of the history from here and there.

> You don't do a merge every time you record a change. You do a merge every
> time somebody *else* records a change.

No, you do a merge every time you want to *apply* someone else's changes to 
your working directory.

>> A git branch is like a darcs repository.
>> A git commit is like a darcs record.
>> A git merge is like a darcs fetch-and-apply.
>
> Except that you don't explicitly keep a record of a darcs fetch-and-apply.

Exactly. Which seems like a downside to me more than an upside. It means you 
have to have separate repos for different versions of the same program, 
duplicating all that history and making it "fragile" in the operational 
sense (as in, too easy to accidentally update a repo with changes that 
shouldn't be there, with no easy way to remove those changes since the fact 
that you fetched them isn't recorded).

> So what you're saying is, the histories in two Git repos don't actually have
> to match, only the file contents?

The histories merge if two histories bring you to the same set of contents. 
Indeed, since each file is stored with a name based on the hash of its 
contents, it's literally impossible to have the same content in two 
different files.

> OK, "linear order within a single branch".

Yes. And that's a *good* thing, I'd posit, for the reasons I mentioned in 
other threads.

>>> As I say, it just annoys me that you have to assign an arbitrary
>>> ordering to changes.
>>
>> It's not really arbitrary. Darcs just ignores the fact that they aren't.
>>
>> If I add function AAA to file BBB and record that change, then add a
>> call to function AAA into file CCC, then record that change, would that
>> really be independent unordered changes in Darcs? That seems awfully
>> fragile.
>
> Darcs doesn't guarantee that a particular combination of patches will
> produce a working combination of files. Neither does Git, or RCS, or CVS.

Yes. But more than that, Darcs doesn't record what your WD looked like at 
the time you created the changes. *That* is the problem.

In Darcs, I'd have much more trouble tracking this bug down. In git, I'd be 
able to see that you created your patch before you knew about my change to 
function AAA, and maybe that's the source of the problem. In Darcs, I don't 
think I have any way of looking at your patch to CCC and saying "what 
version of file BBB was he reading while he was writing file CCC?"

> Changes have descriptions for a reason.

A manually-entered description isn't going to say what versions of the files 
you *didn't* change you were relying on. That's where the commit history in 
git helps out.

>>>> Say you have 25 changes in your Darcs repository, and you want a version
>>>> that applies every change except #23. What do you put in the repository
>>>> to represent that?
>>>
>>> You ask Darcs to revert change #23.
>>
>> And how do you do that? "darcs revert" doesn't do that. "darcs unrecord"
>> throws the change away entirely. Obliterate deletes the patch entirely
>> as well.
>
> "darcs rollback" does it though.

Oh, OK. But again it makes a permanent change in the repository. I guess 
you'd have to clone the entire repository, then roll back that one patch.

> OK, fair enough. But changes within a branch are linearly ordered.

Yes, and that's a good thing. You can trivially reorder them if they're 
independent, but there's no way of knowing whether they're really 
independent.  Git assumes they aren't, and if they are, you can reorder them 
if you care. Darcs assumes they are unless you tell it so.

>> For example, attached is a picture of the last few dozen commits to the
>> Linux kernel.
>
> What we see here is a long tangled history of sequential changes,

I'm not sure how you get a tangle of sequential changes. What does that even 
mean?

> than a set of mostly independent changes which could safely be combined in
> any combination.

Each of those strings of sequential history is a set of independent changes.

I don't think Darcs is any less tangled, or to the extent it is, I'm not 
sure it would be accurate to rearrange them.

Might I ask, why do you care? You're talking about a VCS being a record of 
the history of changes, and your biggest complaint against git seems to be 
that it's actually recording the history of changes. Darcs seems to throw 
away useful information about the history of the changes in the hope that it 
can automatically deduce enough of the history not to break in the future.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/23/2011 12:14, Darren New wrote:
>> "darcs rollback" does it though.
>
> Oh, OK. But again it makes a permanent change in the repository.

It also sounds like it would be sketchy if #24 depended on #23 (or even 
changed something else #23 changed) and now your rollback patch has a merge 
conflict? Or your rollback patch has a merge conflict with someone else's 
changes?

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/23/2011 11:58, Orchid XP v8 wrote:
>>> Apparently this doesn't stop people working on the Linux kernel. But it
>>> seems really clumsy to me.
>>
>> It seems clumsy because you keep thinking git is recording changes. You
>> keep thinking of "changes" instead of "versions".
>
> That's because "changes" are the logical thing to think about. Take a look
> at a bunch of commit messages, and they all tell you about what just *changed*.

No. The history is the logical thing to think about. Commits are a logical 
thing to think about. Changes are *one* logical thing to think about, but I 
think it's easier to generate changes from history than to generate history 
from changes, especially when changes aren't in any particular order.

In other words, changes don't represent all the history. You're throwing 
away the history of "clone" and "pull" and "push" and "apply". All you're 
recording is the changes to the files in the WD, not changes in the 
repository itself.

> Or perhaps you meant if I wanted GHC-6.6 and GHC-HEAD?

No, I meant if I wanted to compile each tagged version in the repository. I 
want to compile GHC-1.0, GHC-1.1, GHC-1.2, GHC-2.0, ....

I have to basically apply every patch in sequence in the entire repository, 
in some unknown order.

In git, all those files are already there.  If it's packed, you might wind 
up applying a lot of patches, but the patches are optimal in that case, 
rather than an accident of history.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

>>> git keeps a history that can tell me what changes rely on other changes
>>> semantically, not just syntactically.
>>
>> How?
>
> Exactly that "linear" order you're complaining about. The DAG of commits
> tells you which changes were written with one version in mind but
> without other changes in mind.

In other words, Git is *guessing* which changes depend on each other 
semantically from which changes were written at the same point in time 
in the same repo.

I could change thing X, and then change thing Y which has nothing to do 
with thing X, and still Git will assume a relationship exists there. 
Darcs, on the other hand, only concerns itself with *real* dependencies. 
It's true Darcs can't guarantee that a particular combination of patches 
will produce runnable code. It's also true that Git can't guarantee that 
the code in any particular commit object is runnable either.

> If I change on April 1 the semantics of function XYZ, then I write code
> on April 3 depending on the new semantics, and you on April 5 write code
> depending on the old semantics, you now have a dependency from your code
> to the April 1 code that isn't recorded anywhere in Darcs. It's recorded
> in git, tho.

For every true dependency, there will be a bazillion spurious ones. So 
it's a case of "Which is worse? Missing some real dependencies, or 
recording millions of fake ones?" Given that the former is much simpler 
conceptually, I'll go with that thanks.

> If I have a repository and I merge in a bunch of your changes and apply
> them, then I merge in a bunch of changes from Jim, I could very well get
> tons of conflicts if Jim didn't apply your changes when he started working.

Is this not the case for every known distributed version control system?

> It seems fragile to me to have a working directory and a repository
> where I can incorporate changes into the repository that I cannot get
> into the working directory to work on.

Why can't you get them into the working directory?

>>> git doesn't have to spend tens of hours applying 240,000 change sets to
>>> the repository in order to give me the latest version of the files.
>>
>> Neither does Darcs.
>
> Sure it does. Delete your working directory.
>
> When you clone git, it pulls down the repository, then creates the
> working directory from that. When you clone darcs, it sounds like it
> pulls down both the repository and the working copy (which would seem
> problematic if the working copy had changes to it that weren't recorded,
> yes?).

Wrong.

It doesn't pull down the working directory at all. Indeed, in the copy I 
put on my webserver, I *deleted* the working directory.

It pulls down the *pristine* copy, which contains only recorded changes. 
[And is compressed.] If you're silly enough to delete that, then you 
just broke your repo. (I'm not sure whether the repair command can fix 
this... I believe so, but I've never tried it. It probably won't be fast 
though.)

>>> git has all kinds of sweet tools to manipulate the repository in ways
>>> Darcs can't very easily.
>>
>> Ways such as what?
>
> Like the bisecting command, just as an example. Or the stash command.

Without looking those up, I don't know what they do.

> Or commiting things in phases.

You mean like if you go to record something and realise you want to 
tweak it first?

> Or efficiently giving me a copy of the files
> as they existed at a specific point in time. (Indeed, since Darcs
> doesn't actually record what order you pulled changes in, it seems Darcs
> can't really even do that inefficiently.)

You could add a tag before you pull anything in. Then if you have 
problems, you can go back to the tag. (Or just query exactly what 
happened after the tag.) But yes, I suppose the fact that you need to 
remember to do this could be considered a weakness. There's no really 
fundamental reason why Darcs couldn't keep a history of what's happened 
to your repo though. (And keep it local to that repo, not part of the 
shared change history.)

> BTW, if you ever want to play, there's a script for git that will import
> the changes from and export to a Darcs repository.

Given the radically different ways in which the two systems work, I 
imagine the history gets pretty mangled in the conversion - no matter 
which system you believe is the "correct" one.

>> 1. I will never wind up "working" on anything that's
>> version-controlled. I
>> am apparently doomed to spend the rest of my /working/ life rebooting
>> people's PCs because Word crashed, rather than doing interesting
>> coding tasks.
>
> <Yoda> And that is why you fail. </Yoda>

Is this the same Yoda who lived in a universe where you can literally 
make inanimate objects physically move just by *believing* that you can?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> So what do you mean "apply"? What happens if your WD matches the
>>> repository, then you do a fetch, then you say "record", what does
>>> Darcs do?
>>
>> Records a new patch reverting all the changes that you didn't apply,
>> presumably.
>
> That sounds really dangerous to me.

Even though it explicitly prompts you whether you want to record each of 
those changes?

>> You can't really use tags for that; you'd have to have seperate repos for
>> v1, v2 and v3. Oh, you *can* put all the patches in one repo, but it's
>> going to get messy very quickly.
>
> See, git has no trouble with that. One repo has all of every version of
> Linux since 2.6.16 or so.

But is that better?

> And a bit fragile. The idea of git is that you have a repo with all the
> history in it. You don't have to chop it into multiple repos in order to
> actually exclude some of the history from here and there.

If Darcs does have a weakness, it's that it mostly assumes that the main 
thing you want to do is perform modifications to the one single "latest 
version" of stuff. It could be made more flexible in this direction, yes.

>> You don't do a merge every time you record a change. You do a merge every
>> time somebody *else* records a change.
>
> No, you do a merge every time you want to *apply* someone else's changes
> to your working directory.

Well, yes, that's what I meant.

>> So what you're saying is, the histories in two Git repos don't
>> actually have to match, only the file contents?
>
> The histories merge if two histories bring you to the same set of
> contents.

I see. I was assuming that if two repos disagree about history, your 
computer would explode or something. So Git is actually smart enough to 
handle that?

>>>> You ask Darcs to revert change #23.
>>>
>>> And how do you do that? "darcs revert" doesn't do that. "darcs unrecord"
>>> throws the change away entirely. Obliterate deletes the patch entirely
>>> as well.
>>
>> "darcs rollback" does it though.
>
> Oh, OK. But again it makes a permanent change in the repository. I guess
> you'd have to clone the entire repository, then roll back that one patch.

I admit, I'm surprised it actually records a patch for it. I would have 
expected it to just alter the WD. But whatever. If you rollback the 
change and then get bored with it, you can then erase the rollback 
patch. [Provided you didn't give it to anyone else.]

I'm guessing this curious glitch is related to the designer's "one true 
latest version" mentallity. The whole *point* of storing history as a 
set of changes should be to make this kind of task easy.

> Might I ask, why do you care? You're talking about a VCS being a record
> of the history of changes, and your biggest complaint against git seems
> to be that it's actually recording the history of changes. Darcs seems
> to throw away useful information about the history of the changes in the
> hope that it can automatically deduce enough of the history not to break
> in the future.

This, fundamentally, seems to be what it all comes down to. You seem to 
think that this information is *useful*, whereas to me it's annoying 
clutter that I'd rather not have to waste time explicitly micro-managing.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 4/23/2011 12:24, Orchid XP v8 wrote:
> In other words, Git is *guessing* which changes depend on each other
> semantically from which changes were written at the same point in time in
> the same repo.

No. git is merely recording what changes from your repository you had 
already applied to your working directory at the time you made the change. 
It's not guessing that it's semantically meaningful. It's recording it in 
case it is.

> I could change thing X, and then change thing Y which has nothing to do with
> thing X, and still Git will assume a relationship exists there. Darcs, on
> the other hand, only concerns itself with *real* dependencies.

But if you change Y that depends on me *not* having changed X, that's a real 
dependency that darcs does *not* track.

> It's also true that Git can't guarantee that the code in any
> particular commit object is runnable either.

But *I* can guarantee that code in any particular commit object is runnable. 
I can test it. I can't do that with darcs, because fetching new stuff might 
retroactively change whether something works in a way that isn't recorded in 
the repository.

> For every true dependency, there will be a bazillion spurious ones. So it's
> a case of "Which is worse? Missing some real dependencies, or recording
> millions of fake ones?" Given that the former is much simpler conceptually,
> I'll go with that thanks.

I think your "fake dependency" aversion is kind of silly, since nobody 
really records fake dependencies.

>> If I have a repository and I merge in a bunch of your changes and apply
>> them, then I merge in a bunch of changes from Jim, I could very well get
>> tons of conflicts if Jim didn't apply your changes when he started working.
>
> Is this not the case for every known distributed version control system?

Yes. But git lets me resolve the issue, while darcs makes it a very manual 
process for me to figure out *why* Jim's changes conflict.  If I go to merge 
Jim's changes, darcs gives me no help. Git tells me what version Jim's 
changes are *supposed* to merge cleanly into.

>> It seems fragile to me to have a working directory and a repository
>> where I can incorporate changes into the repository that I cannot get
>> into the working directory to work on.
>
> Why can't you get them into the working directory?

Because that messes up my working directory in a way I can't recover from.

> It pulls down the *pristine* copy, which contains only recorded changes.
> [And is compressed.] If you're silly enough to delete that, then you just
> broke your repo. (I'm not sure whether the repair command can fix this... I
> believe so, but I've never tried it. It probably won't be fast though.)

OK, so darcs doesn't record only the changes, but the changes and then the 
result of applying all those changes, *and* you have a working directory. 
That makes a bit more sense I guess.

>> Like the bisecting command, just as an example. Or the stash command.
> Without looking those up, I don't know what they do.

Ways of saving your changes temporarily in a different part of the repository.

>> Or commiting things in phases.
>
> You mean like if you go to record something and realise you want to tweak it
> first?

Yes. Resolving merges a bit at a time, compiling and testing in between, 
rather than having the "record" and "commit" be the same action.

>There's no really fundamental reason why Darcs
> couldn't keep a history of what's happened to your repo though.

I agree. It just doesn't.

 > (And keep it
> local to that repo, not part of the shared change history.)

No, that doesn't work, because you still want that history when you clone 
the repository or it's useless in the bigger picture.  Especially when 
cloning the repository is how you make a temporary branch.

>> BTW, if you ever want to play, there's a script for git that will import
>> the changes from and export to a Darcs repository.
>
> Given the radically different ways in which the two systems work, I imagine
> the history gets pretty mangled in the conversion - no matter which system
> you believe is the "correct" one.

The git import function works by running a script to "get the next version" 
and then checking it in, over and over, until it's all checked in. If you 
can write a script that says "make a file that holds the commit message, and 
a command line to fetch the next version", then you have enough for git.

Of course, darcs doesn't really have a "next version" concept, so that could 
be problematic.

> Is this the same Yoda who lived in a universe where you can literally make
> inanimate objects physically move just by *believing* that you can?

You have a point.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 4/23/2011 12:38, Orchid XP v8 wrote:
>>>> So what do you mean "apply"? What happens if your WD matches the
>>>> repository, then you do a fetch, then you say "record", what does
>>>> Darcs do?
>>>
>>> Records a new patch reverting all the changes that you didn't apply,
>>> presumably.
>>
>> That sounds really dangerous to me.
>
> Even though it explicitly prompts you whether you want to record each of
> those changes?

Yes.

>>> You can't really use tags for that; you'd have to have seperate repos for
>>> v1, v2 and v3. Oh, you *can* put all the patches in one repo, but it's
>>> going to get messy very quickly.
>>
>> See, git has no trouble with that. One repo has all of every version of
>> Linux since 2.6.16 or so.
>
> But is that better?

I'd say so. YMMV.

> If Darcs does have a weakness, it's that it mostly assumes that the main
> thing you want to do is perform modifications to the one single "latest
> version" of stuff. It could be made more flexible in this direction, yes.

Yeah, that's it. And that everyone is pretty much working on the same 
version of stuff. Works for small scale, not so much for large scale, I think.

>>> You don't do a merge every time you record a change. You do a merge every
>>> time somebody *else* records a change.
>>
>> No, you do a merge every time you want to *apply* someone else's changes
>> to your working directory.
>
> Well, yes, that's what I meant.

Well, that's a different thing. I can record a dozen changes which you apply 
only once.  In the linux kernel it seems to be about 15:1 ratio.

>>> So what you're saying is, the histories in two Git repos don't
>>> actually have to match, only the file contents?
>>
>> The histories merge if two histories bring you to the same set of
>> contents.
>
> I see. I was assuming that if two repos disagree about history, your
> computer would explode or something. So Git is actually smart enough to
> handle that?

There's only one history. Nothing you put into a repo ever changes or 
disappears. So both histories are in the repo, and at the point where I drew 
yours in, it got linked into my history as a loop earlier in the development.

> I'm guessing this curious glitch is related to the designer's "one true
> latest version" mentallity. The whole *point* of storing history as a set of
> changes should be to make this kind of task easy.

Yeah, I think that's the basic problem I have with Darcs. All the things 
that make git complicated compared to darcs have to do with having one 
repository having lots of different versions being developed at different 
speeds.

> This, fundamentally, seems to be what it all comes down to. You seem to
> think that this information is *useful*, whereas to me it's annoying clutter
> that I'd rather not have to waste time explicitly micro-managing.

You really don't have to micromanage it. The git commands are all pretty 
much isomorphic to the darcs commands. It's extremely useful when you merge 
in a change and something breaks, so you can easily go "Oh, I see why, 
because his change says "outputs index counter" and I changed the output 
function *since* he started work on that."

Without that clue, you have to actually look at the "outputs index counter" 
change and read it to see what version of the output routines he's 
expecting, which can be especially confusing if he *wrote* the patch after 
you changed the output function but before he merged and applied your patch.

I'm not all that sure how you can't see how that's helpful. :-)

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

>> This, fundamentally, seems to be what it all comes down to. You seem to
>> think that this information is *useful*, whereas to me it's annoying
>> clutter
>> that I'd rather not have to waste time explicitly micro-managing.
>
> You really don't have to micromanage it. The git commands are all pretty
> much isomorphic to the darcs commands. It's extremely useful when you
> merge in a change and something breaks, so you can easily go "Oh, I see
> why, because his change says "outputs index counter" and I changed the
> output function *since* he started work on that."
>
> Without that clue, you have to actually look at the "outputs index
> counter" change and read it to see what version of the output routines
> he's expecting, which can be especially confusing if he *wrote* the
> patch after you changed the output function but before he merged and
> applied your patch.
>
> I'm not all that sure how you can't see how that's helpful. :-)

There really has to be a better way of solving this problem than 
serialising the entire change history forever...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 4/24/2011 1:35, Orchid XP v8 wrote:
> There really has to be a better way of solving this problem than serialising
> the entire change history forever...

Well, as I see it, both git and darcs stores a DAG. Git stores a DAG of 
collections-of-files, and Darcs stores a DAG of collections-of-changes. Git 
stores enough information that you can reproduce the changes from the files 
well after the fact. Darcs does not store enough information that you can 
reproduce files from changes reliably (in that I can't tell what files you 
were looking at when you made a particular change, for example).

So, basically, there are changes that have known dependencies, and changes 
that have unknown dependencies. Git records all history explicitly, 
including dependencies that may or may not actually exist. Darcs assumes if 
you don't tell it about the dependencies that they specifically don't exist. 
Darcs also fails to record anti-dependencies. Git lets you put multiple 
histories in the same repository, while Darcs can't really represent 
multiple histories so you wind up with lots of individual repositories to 
manage with apparently no good tools to compare them (since the DAG between 
different repositories is intentionally discarded when you clone the 
repository, as I understand it).

I think if you're working on a small project, either by yourself or with a 
small team you're in communication with on a frequent basis, either might 
work. Either seems pretty easy to understand.

The only way of improving on serializing the change history is to specify in 
Darcs exactly what you rely upon and what you don't, which would seem to 
require actually doing a full analysis of the program every time you check 
in a change. If function XXX relies on the behavior of function YYY, and you 
change function XXX and I change YYY, there may or may not be a dependency 
between those two changes, depending on whether I "break" your XXX with my 
change to YYY. But then you have to define "break".  I can see, however, how 
a language like Haskell or Eiffel or something with 100% test coverage 
available to every repository holding the project could make that mostly 
feasible.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 20/04/2011 10:44 AM, Invisible wrote:

> I had assumed that all DVCSs were the same, but I now see that at least
> Git and Darcs use fundamentally different models.

This is somewhat related:

http://koweycode.blogspot.com/2011/04/why-darcs-users-care-about-consistency.html

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message