>>> 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

On 4/28/2011 1:32, Orchid XP v8 wrote:
> http://koweycode.blogspot.com/2011/04/why-darcs-users-care-about-consistency.html

Thanks. That's interesting.

"""
The most well-known remaining cause of blowups in theory 2 is the problem of 
"conflict fights" where one side of the conflict resolves the conflict and 
gets on with their life without propagating the resolution back to the other 
side.
"""

This is basically the source of the mess in git, also. In the whole blah 
going on here: http://bramcohen.livejournal.com/74462.html I'm not sure I 
can understand how presenting that work as a set of patches makes sense. 
You'd wind up with a repository that changes A into B twice and B into A 
once without any particular ordering between them, so I'm lost as to how 
Darcs would handle that.

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

Post a reply to this message

>> http://koweycode.blogspot.com/2011/04/why-darcs-users-care-about-consistency.html
>
> Thanks. That's interesting.

Interesting, disturbing, whatever you want to call it. ;-)

All describing problems I've never come across. Then again, when your 
development team consists of one person...

> """
> The most well-known remaining cause of blowups in theory 2 is the
> problem of "conflict fights" where one side of the conflict resolves the
> conflict and gets on with their life without propagating the resolution
> back to the other side.
> """

Given the entire purpose of *distributed* revision control... yeah, that 
would be a problem. (Exponential-time merge worries me more though.)

> This is basically the source of the mess in git, also. In the whole blah
> going on here: http://bramcohen.livejournal.com/74462.html I'm not sure
> I can understand how presenting that work as a set of patches makes
> sense. You'd wind up with a repository that changes A into B twice and B
> into A once without any particular ordering between them, so I'm lost as
> to how Darcs would handle that.

You understand that Darcs *does* have an ordering between *related* 
patches, right? It's only *unrelated* patches that have no order 
relationship. I can flip the same line of code back and forth 20 times, 
and record that as 20 patches, and they will have a strictly linear 
ordering.

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

Post a reply to this message

On 4/29/2011 2:55, Orchid XP v8 wrote:
> You understand that Darcs *does* have an ordering between *related* patches,

Yes, I figured that.

Indeed, that's my main complaint with the whole concept: the idea that 
simply because two patches are in different files doesn't mean they're 
unrelated. If I implement foo() in file abc.c and call foo() in file def.c, 
those are not two unrelated patches.

> right? It's only *unrelated* patches that have no order relationship. I can
> flip the same line of code back and forth 20 times, and record that as 20
> patches, and they will have a strictly linear ordering.


So, you clone a repository and I clone a repository.

You create a file called XX with the line Hello in it.

I create a file called XX with the line Goodbye in it.

We both record our changes.

I then change my XX file to say "Hello\nGoodbye".

You change your XX to say "Goodbye\nHello".

We both record our changes.

I then change my XX file to say "Hello". You change yours to say "Goodbye".

We both record our changes.

We attempt to merge our repositories.

Can you try this on a blank repository on your machine and tell me what happens?

Resolving this in git is very straightforward. You can just pick one that's 
right and say "Henceforth, that's the answer". Or you can just grab all the 
changes and basically never merge them back together again (say, if you have 
two distros in the same repository).

Also, what happens if I rename a file from XXX to YYY and you rename it from 
XXX to ZZZ?  Do I wind up with both YYY and ZZZ in my repository?

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

Post a reply to this message

On 4/29/2011 2:55, Orchid XP v8 wrote:
> You understand that Darcs *does* have an ordering between *related* patches,
> right? It's only *unrelated* patches that have no order relationship.

BTW, the problem here is that those patches are *not* related. Each branch 
down the side is a separate Darcs repository. So the first guy takes A, 
makes it a B, then patches it back to A. In parallel, in *your* repository, 
you independently take A and make it into B. Now everyone copy all the 
patches from everyone else. Do I wind up with A or B? I'm not sure there's 
an answer there that makes sense from a technical perspective.

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

Post a reply to this message